cs 4240: rethinking some oop ideas and terms for ooa&d
DESCRIPTION
CS 4240: Rethinking Some OOP Ideas and Terms for OOA&D. Readings: Chap. 8 in Shalloway and Trott (referred to as S&T in these slides) Wikipedia on information hiding This unit is about principles and concepts – study the readings!. In Chap. 8, authors argue:. - PowerPoint PPT PresentationTRANSCRIPT
CS 4240: Rethinking SomeOOP Ideas and Terms for OOA&D
Readings: Chap. 8 in Shalloway and Trott
(referred to as S&T in these slides)Wikipedia on information hiding
This unit is about principles and concepts – study the readings!
In Chap. 8, authors argue:
Designers need to think about OO in a "new", "fresh", "non-traditional" wayin particular, about three terms:
objects, encapsulation, inheritance
Is this really new? Maybe better to say:more mature, experienced perspectivemore abstract
Later we’ll use language features to support higher-level design needs
But in design, focus on higher-level issues
What are objects?
We learn early that they’re:Data with methodsVisibility: public, private, etcSupports information hiding, encapsulation
Good match for:domain conceptsdata objects
S&T's “New” View of Objects
An object is:
An entity that has responsibilitiesmay include providing and managing
information
Focus here on what it does, not howAn external viewWe can design using objects defined this
way (without other details)
Adopt this view?
Let's think this way for OO analysis and design.What's the role of the object?
From the point of view of the rest of the systemWhat does it provide us? What does it do for us?
Makes sense for the conceptual and specification levels of design.
More general: non-domain, non-data objects
S&T's New View of Encapsulation
Old/Beginner/Implementation view of encapsulation: hiding data inside an object
New view: hiding anything, including:implementationderived classesdesign detailsinstantiation rules
Encapsulation means hiding
Examples. (See book too.)Hiding data
Encapsulating data in objects; getters; etc.
Hiding method implementation detailsPolymorphism with pointers to superclasses, interfaces;
abstract methods
Hiding other objectsComposition; delegation; Façade pattern
Hiding typepointers to superclasses or interfaces; factories for
creating objects
Really a New View of Encapsulation?
Information hiding: (from Wikipedia)Information hiding is the principle of segregation of the
design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed.
The protection involves providing a stable interface which protects the remainder of the program from the implementation (the details that are most likely to change).
Read: http://en.wikipedia.org/wiki/Information_hiding
Information Hiding and David Parnas
Term introduced in a famous paper:David Parnas, "On the Criteria to Be Used in Decomposing Systems Into Modules.”Comm. of the ACM, 1972.
Parnas is an important figure in SW Engin.Keep in mind about Information [sic] Hiding:
“Information” does not mean just data encapsulationNot just limited to OO
S&T's View of Inheritance
Don't focus so much on inheritance for reuseRecall "specialization form" of inheritance?
Override methods to created different, specialized behavior
Extension form: add new behaviors (also applies here)
S&T say, for design, think about inheritance as a way to identify things with common behaviorsNot about implementation. We’re doing design. Inheritance/generalization in design may not lead to
inheritance in implementation!
Book's example: page 122
Class Pentagon has drawBorder()Subclass PentagonSpecialBorder() overrides
methodSeems fine! The IS-A relationship is true, and can
and should be used in design!Problems if you implement it that way:Weak cohesion: the subclass contains pentagon-stuff
and border-stuffPoor reuse: other shapes need special-border code?Doesn't scale: other dimensions of variability (we've
seen this – inheritance “diamonds”)
Important Encapsulation Principle
Find What Varies and Encapsulate ItGang of Four wrote about this (p. 123):Consider what should be variable in your design.Don't focus on what might force a design
change.Instead, what do you want to be able to change
without large-scale design change?Encapsulate that thing that you want to vary.
Example: Hiding "Type”
A reference (or pointer) X can be assigned the address of an object that is:the declared class of the referencea class that is a subclass of class of referencea class that implements interface of reference
Client-code using X doesn't have to know which What’s “behind X” could change without affecting
design of client-codeType encapsulation: The “real” type is “hidden”
Comments
You've seen many examples of this!Study two examples in S&T, pp. 124-127Animal generalization, with variations in:
how it moves (walk, fly, swim)what it eats (meat, veggies,...)Understand what’s said about UML diagrams
Money, Currency classesConversion is supported, even historicalNote this is hidden from client SalesReceipt
Animal Example
Encapsulate movement behaviorNote superclass is abstract (could be an interface)
Commonality and Variability Analysis (CVA)
“CVA” as described by James CoplienCommonality analysis
Goal: determine family members and how they are the same
Family members: elements that appear in the same situation or perform the same function
Note: this is a process of identifying and analyzing generalizations
Variability Analysis
Different elements are not exactly the sameAre the differences enough to mean they're not
family members?If not, then you're showing how family members
vary. This is variability analysis.Can't talk about variability within a family unless you
have defined the family (i.e. done commonality analysis).
"CA" and "VA" are probably not linear, sequential processes. Iterative activity!
Coplien says:
CA seeks structure that is unlikely to change over time.
VA captures structure that is likely to change.VA only makes sense in terms of the context
defined by CA.CA gives an architecture longevity.VA drives architecture’s “fitness for use”. (I.e.
can it successfully solve specific problems?)
(Paraphrased from quote on p. 128 in S&T book)
An Aside about Software Reuse
There are fields in SW Engin.: Software reuse, domain engineering, product-line development
CVA is important in domain analysisIdentifying common objects in a product domain
or product lineWhat's the same? How do things vary?
Goal: build an architecture or components that can be re-used to develop many products in the domain or product line.
S&T on Identifying Classes
The naive approach: find nouns, verbs, etc.S&T say: often leads to too many classes
Contrast with CRC: classes, responsibilities, collaborations
S&T talk about:Objects are entities with responsibilitiesInheritance? Focus on finding commonalities in things
to identify general abstractionsThen make these abtractions/interfaces/layers in your
design.
Back to 3 Levels of Design Perspective
For documenting and doing design, different levels of perspective:Conceptual; Specification; Implementation
Commonality Analysis and Conceptual levelWhat are the entities and their commonalities?What are the abstractions? These will become
superclasses, interfaces, etc.
At the Specification Level:Need APIs to support what's commonAnd, must be able to hide variability behind these APIs
Summary
OO Design: different kind of thinking about objects, encapsulation, generalizationthan what you learn as an OO Programmer
Encapsulation: Hiding something from clientSame idea as information hidingA rule: Find What Varies and Encapsulate It
Commonality and Variability AnalysisAn activity in OOA and OOD that can help produce
stronger designs