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