3/15/05h-1 © 2001 t. horton cs 494 object-oriented analysis & design evaluating class diagrams...
TRANSCRIPT
![Page 1: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/1.jpg)
H-13/15/05© 2001 T. Horton
CS 494
Object-Oriented Analysis &
Design
Evaluating Class Diagrams
• Topics include:• Cohesion, Coupling• Law of Demeter (handout)• Generalization and specialization• Generalization vs. aggregation• Other aggregation issues
![Page 2: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/2.jpg)
3/15/05 H-2
First Example: Observer
• This part of the course discusses:– Peter Coad’s ideas on when to use inheritance– The Observer design pattern– Support for Observer in the Java class library– Why this might be a poor design
![Page 3: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/3.jpg)
3/15/05 H-3
Coad’s Five Criteria for When to Inherit
• Peter Coad in book Java Design• Encapsulation is weak within a class
hierarchy• Only use inheritance when:
– “Is a special kind of”, not “Is a role played by”.– Never need to transmute an object to be in
some other class– Extends rather than overrides or nullifies– Does not subclass what is merely a utility class– For problem domain (PD) objects, it is a special
kind of role, transaction, or thing
![Page 4: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/4.jpg)
3/15/05 H-4
Example: Java’s Observer/Observable
• Coad argues Java’s implementation of this design pattern is poor.
• Observer interface: public interface Observer { void update (Observable observed, Object argument); }
• Observable superclass. Has operations: addObserver(), deleteObserver(), deleteObservers(), notifyObservers()
![Page 5: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/5.jpg)
3/15/05 H-5
Class Diagram: Observable/Observer
• Top two classifiers from java.util
![Page 6: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/6.jpg)
3/15/05 H-6
Java’s Observable Superclass
• Does it meet Coad’s criteria? No!– We’re subclassing a utility class
• A better implementation:– Make Observable an interface (not a
superclass)– Factor out the “observable-related” stuff into
an ObservableComponent object• This is a reusable utility class• Implements storing and notifying observers
![Page 7: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/7.jpg)
3/15/05 H-7
Observable Interface, ObservableComponent Class
![Page 8: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/8.jpg)
3/15/05 H-8
Coad’s Observer Interface
• Java’s Observer interface won’t work with this model: public interface Observer { void update (Observable theObserved, Object argument); }
• First parameter is an Observable– We need it to be anything that implements our
IObservable interface
• Coad’s solution: Replace with a new Observer interface that looks like this: public interface IObserver { void update (Object theObserved, Object argument); } Or, should it be IObservable theObserved ???
![Page 9: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/9.jpg)
3/15/05 H-9
Cohesion and Inheritance
![Page 10: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/10.jpg)
3/15/05 H-10
Cohesion
• How diverse are the things inside an “entity”– A what? Module, function,… In OO a class.
• What’s this mean?– Class should represent a single abstraction
– Or, it should address a single general responsibility
![Page 11: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/11.jpg)
3/15/05 H-11
Problems Created by Bad Cohesion
• Hard to understand the class• If two abstractions grouped into one class,
that implies a one-to-one relationship– What if this changes?
• Often we specialize a class along a dimension– This new thing is like the existing one except
we extend it in one area (dimension)– Problems arise when each of the several
abstractions need such specialization
![Page 12: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/12.jpg)
3/15/05 H-12
The “Multiplicity” Problem
• Consider an Account class that holds:– Customer name, address, tax ID, Account
status, etc.• What if one customer needs two accounts?
– Two Account objects, but each stores name and address
• What if one account has two owners?– You can’t do this, unless you create a
collection in each Account to hold owner info
![Page 13: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/13.jpg)
3/15/05 H-13
Specializing along Dimensions
• Let’s say we need variations on class Account– First, based on account type: Cash Account, Credit
Account– Second, based on customer type: Individual Account,
Institutional Account• These are two dimensions, but are they mutually
exclusive?– We often compose along two dimensions– E.g. Individual Cash Account, Individual Credit Account,
etc.• Specialization often implemented as inheritance:
Do we want multiple inheritance?
![Page 14: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/14.jpg)
3/15/05 H-14
Inheritance Diamonds
Account
Cash Account Credit Account Individual Account Instiutional Account
Individual Cash Account Individual Credit Account
Two more classes here
• Structures like this cause messy problems!
![Page 15: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/15.jpg)
3/15/05 H-15
Separating Abstractions
Account
Cash Account Credit Account Individual Customer Instiutional Customer
Customer
*
owner
1..*
• Composition across dimensions achieved by aggregation
• You can see how this improves earlier problem too
![Page 16: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/16.jpg)
3/15/05 H-16
How to Achieve Better Cohesion
• Some of this is just good OO experience• We can learn from database normalization
– Eliminate redundancy– Attributes should have a single value and should not have
structure (repeating groups of things)– Attributes always describe an instance of its containing
class• That’s what attributes are all about! State values that
define a particular instance
• Note: there are always tradeoffs! Sometimes we combine abstractions into one class for efficiency.
![Page 17: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/17.jpg)
3/15/05 H-17
Coupling and Class Design
• How dependent an object/class is on the world around it– How many connections
– Nature of the connections
– Will changes cause a “ripple effect”?
• Our goals:– Reduce coupling if possible
– Improve nature of necessary coupling
![Page 18: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/18.jpg)
3/15/05 H-18
Forms of Coupling (from Richter)
• Identity Coupling– An object contains a reference or pointer to
another object– Eliminate associations or make them one-way
• Representational Coupling– An object refers to another through that
object’s interface• How it does this affects the degree of
coupling
![Page 19: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/19.jpg)
3/15/05 H-19
Forms of Coupling (cont’d)
• Subclass Coupling– Object refers to another object using a subclass
reference for that object• Not the more general superclass
– A client should refer to the most general type possible• Why? Subclasses may be added later, possibly by
someone else– Try to write code that minimizes dependencies on
subclass details• Instead rely on the common interface defined in the
superclass• Factory patterns for creation
![Page 20: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/20.jpg)
3/15/05 H-20
Reminder: Use Java Interfaces to Avoid Subclass Coupling
• Java’s interfaces; C++ classes with pure virtual functions and no data members
• Interfaces define a role not a class-abstraction– Many classes can pay that role
THE POINT:• We can define a function parameter or pointer
in terms of the role (interface) instead of the class type
![Page 21: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/21.jpg)
3/15/05 H-21
Forms of Coupling (cont’d)
• Inheritance coupling– A subclass is coupled to its superclass at compile-time
• In general, prefer late to early– Seems like the only way to do things, but ask:
While the program executes, does an object need to change its subclass?
– Aggregation is supported at run-time– Examples:
• PARTS: subclasses for Manager and Employee?
![Page 22: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/22.jpg)
3/15/05 H-22
Shy Code and the Law of Demeter
• See handout on the Law of Demeter
• Summary: An object’s method should only call other methods that belong to:– Itself (the current object)– Any parameter object that was passed to it– An object it created– Any of its components objects
• What does this rule out? (Ponder that.)• Delegation
![Page 23: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/23.jpg)
3/15/05 H-23
Generalization/Specialization: When?
• Why might you choose to introduce a super-class?– A true “Is-A” relationship in the domain model– Two or more classes share a common implementation
• Rule: “Write once!”– Two or more classes share a common interface
• Can use super-class as parameter type• But interfaces solve this problem too
• A subclass specializes its super-class by one of:– Adding state info in terms of an attribute– Adding state info in terms of an association– Adding behavior in terms of a new method– Replacing behavior by overriding a method
![Page 24: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/24.jpg)
3/15/05 H-24
Generalization/Specialization: When Not?
• Avoid distinctions based on state of an instance
• Why? Objects change state!
• Solutions:– Replace with aggregation. How?– Factor out state-specific “extensions” to attributes and
operations into a second object– Attach that object as needed
• Example: the State design pattern from the Gang of Four book
![Page 25: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/25.jpg)
3/15/05 H-25
The State Design Pattern
• A connection can be in various states– Handles requests differently depending on state
• Connection delegates requests to its state object– Which changes dynamically
![Page 26: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/26.jpg)
3/15/05 H-26
Generalization/Specialization: When Not? (2)
• Concrete super-classes are often a bad idea– Consider example of Manager as a sub-type of
Employee– Implies Managers inherit every property of
Employee• Nothing can be unique to non-Managers!
• Reminder: Specialization along multiple dimensions is often better done with aggregation– See earlier example of Account and Customer
![Page 27: 3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)](https://reader035.vdocuments.mx/reader035/viewer/2022062407/56649da05503460f94a8b82b/html5/thumbnails/27.jpg)
3/15/05 H-27
Generalization/Specialization: When Not? (3)
• Where to place properties that are common to some but not all subclasses?– This can get ugly! – Intermediate subclasses? Mix-in classes? Helper
classes?
• Do not (repeat, do not) use multiple inheritance when it’s really aggregation– Ask the “Is-A” question.– Liskov substitutability principle:
• An instance of a child class can mimic the behavior of the parent class and should be indistinguishable from an instance of the parent class if substituted in a similar situation.