Transcript cs4240-f10-chap8.ppt

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:
Designers need to think about OO in a
"new", "fresh", "non-traditional" way
in particular, about three terms:
objects, encapsulation, inheritance
Is this really new? Maybe better to say:
more mature, experienced perspective
more abstract
Later we’ll use language features to support higherlevel design needs
But in design, focus on higher-level issues
What are objects?
We learn early that they’re:
Data with methods
Visibility: public, private, etc
Supports information hiding, encapsulation
Good match for:
domain concepts
data objects
S&T's “New” View of Objects
An object is:
An entity that has responsibilities
may include providing and managing
information
Focus here on what it does, not how
An external view
We 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 system
What 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:
implementation
derived classes
design details
instantiation rules
Encapsulation means hiding
 Examples. (See book too.)
 Hiding data
Encapsulating data in objects; getters; etc.
 Hiding method implementation details
Polymorphism with pointers to superclasses,
interfaces; abstract methods
 Hiding other objects
Composition; delegation; Façade pattern
 Hiding type
pointers 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 encapsulation
Not just limited to OO
S&T's View of Inheritance
 Don't focus so much on inheritance for reuse
 Recall "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 behaviors
Not 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
method
 Seems 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-stuff
Poor 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 It
Gang 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 reference
a class that is a subclass of class of reference
a 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-code
 Type encapsulation: The “real” type is “hidden”
Comments
You've seen many examples of this!
Study two examples in S&T, pp. 124-127
Animal generalization, with variations in:
how it moves (walk, fly, swim)
what it eats (meat, veggies,...)
Understand what’s said about UML diagrams
Money, Currency classes
Conversion is supported, even historical
Note this is hidden from client SalesReceipt
Animal Example
Encapsulate movement behavior
Note superclass is abstract (could be an interface)
Commonality and Variability Analysis (CVA)
“CVA” as described by James Coplien
Commonality 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 same
 Are 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 analysis
Identifying common objects in a product domain
or product line
What'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 responsibilities
Inheritance? Focus on finding commonalities in things
to identify general abstractions
Then 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 level
What 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 common
And, must be able to hide variability behind these
APIs
Summary
 OO Design: different kind of thinking about
objects, encapsulation, generalization
than what you learn as an OO Programmer
 Encapsulation: Hiding something from client
Same idea as information hiding
A rule: Find What Varies and Encapsulate It
 Commonality and Variability Analysis
An activity in OOA and OOD that can help produce
stronger designs