CS 4240: Rethinking Some OOP Ideas and Terms for OOA&D

1. 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!

2. 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

3. 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

4. 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)

5. 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

6. 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

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

8. 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

9. 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

10. 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!

11. 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”)

12. 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.

13. 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”

14. 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

15. Animal Example • Encapsulate movement behavior • Note superclass is abstract (could be an interface)

16. 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

17. 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!

18. 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)

19. 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.

20. 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.

21. 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

22. Summary • OO Design: different kind of thinking about objects, encapsulation, generalizationthan 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