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 higher- level 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:

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, 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 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