Object Design Principles II

1. Object Design Principles II Elizabeth Bigelow School of Computer Science Carnegie Mellon University

2. Exam • Will not contain Chapter 12 or Chapter 13 • Will primarily test fluency • Some interpretation questions • Mostly modeling questions • Will be long

3. Packages and DeploymentDiagrams • Packages used to simplify diagrams • Dependencies are most common association between packages—used for analysis for where they can be reduced or where changes should be made • Many people use packages for components in deployment diagrams • Note that all contents should be within a “node” on a deployment diagram. Packages allow you to do this

4. Basic Design Questions • How can we measure connascence (or cohesion)? • What makes a class “good” in this respect • In order to answer this, we’ll have to cover some more theory that looks abstruse at first glance • A little practice with the terminology and principles will show that it has practical basis and is intuitive (but not at first!)

5. Golden Rules of Object (or most any other design) • Minimize coupling • Increase cohesion

6. & so what anyhow? • Increase in maintainability, understandability • robustness (I.e., avoiding crash & burn…) • general principles which allow you to decide how to set up a class hierarchy and eventually give trade-offs for component and class design • remember: theoretically you can set up a hierarchy any way that you want and put operations wherever you want--but you lose the value of object languages and design if you’re too random

7. Examples • Dogs and Owners • Which design is best and why? • Geometric Library • What could go wrong when you invoke operations?

8. Domains • Domain used slightly differently here--groups of classes • Foundation, Architecture, Business, Application

9. Foundation • useful across all businesses and architectures • (semantic,structural, fundamental) • Date,Time, Angle, Money • Stack, Queue, BinaryTree, Set • Integer, Boolean, Char • Don’t do these at home!

10. Architecture • Classes valuable for one implementation architecture • Human-interface classes (Window, CommandButton) • Database-manipulation classes (Transaction, Backup) • Machine-communication classes (Port, RemoteMachine)

11. Business Classes • Useful for one industry or company • Relationship classes (AccountOwnership for bank, Patient Supervision for hospital nurse) • Role classes (Customer, Patient) • Attribute classes (properties of things--Balance, BodyTemperature)

12. Application • Classes valuable for one application • Event recognizer classes (event daemons, PatientTemperatureMonitor) • Event manager classes (carry out business policy--WarmHypothermicPatient)

13. Where do we get classes for each domain • Foundation -buy • Architectural--buy from vendors of hardware or software infrastructure--need tailoring for compatibility with foundation classes • Business--usually have to build; changing a bit with movement to components • Application--almost always have to build

14. Encumbrance • Measure of how far a class sits above the fundamental domain • Encumbrance measures total ancillary machinery of a class (i.e.--other classes on which it must relying order to work • Direct class-reference set of a class C is the set of classes to which C refers directly

15. Encumbrance, Continued • If direct class reference set of C is C1, C2, C3, Indirect-class reference set of C is the union of the direct class-reference set of C and the indirect class reference sets of C1, C2, …CN • Direct encumbrance of a class is the size of its direct class-reference set. The indirect encumbrance of a class is the size of its indirect class reference set

16. More Intuitively (:-) ) C C C1 C2 C3 C1 C2 C3 Direct Class Reference Set Encumbrance = 3 c21 c22 c11 c12 c31 c32 F1 F2 F3 F4 F5 Indirect Class Reference Set Encumbrance = 13

17. Concrete Example Rectangle 4 Point 3 Length 2 Boolean 0 Real 0 Numbers are indirect encumbrance

18. Use of encumbrance • Measure of class sophistication--how high the class is above the fundamental domain • Classes in higher domains have high indirect encumbrance and those in lower, low indirect encumbrance • Unexpected indirect encumbrance may indicate fault in class design--high indirect encumbrance in a low domain, there may be a fault in class cohesion • If class in high domain has low indirect encumbrance, probably designed fromscratch rather than reusing intermediate classes from library

19. Law of Demeter • Strong law--variable can only be a variable defined in a class itself • Weak law --defines variable as being either a variable of the class or one it inherits from its superclass

20. Formal Law of Demeter • For an object obj of class C and for any operation op defined for obj, each target of a message within the implementation of op must be one of the following objects • the object itself • object referred to by an argument within op’s signature • object referred to by a variable of obj (including any object within collections referred to by obj) • an object created by op • an object referred to by a global variable

21. So what? • Frees designer of C’s superclasses to redesign their internal implementation • Enhances understandability of C, because someone trying to understand the design of C isn’t continually dragged into the implementation details of C’s superclasses or those of a completely unrelated class • Minimizes connascence across encapsulation boundaries

22. Class cohesion • Class cohesion is the measure of how well the features of the class (operatiions and attributes) belong together in a single class • Mixed-instance class cohesion has elements that are undefined for some objects instantianated from the class. • Mixed-domain class cohesion has element that refers to an extrinsic class belonging to a different domain. • Mixed-role cohesion has an element that refers to an extrinsic class belonging to the same domain • Try these concepts against the dog owner handouts

23. So? • Mixed-instance cohesion results in greatest design and maintenance problems • Mixed-role cohesion tends to result in fewest problems • Classes with no mixed-instance, mixed-domain, or mixed-role cohesion problems are the most reusable. • And, in real life, reusability is a prime reason that object orientation was adopted in the first place.

24. Class versus type • Type is the abstract or external view of a class (purpose of the class, class invariant, attributes, operations, operations’ preconditions and postconditions, definitions and signatures) • Class is the implementation of a type--there may be several implementations, each with its own internal design

25. Remember subtypes? Subclasses? • Subclass is distinct from subtype • If S is a true subtype of T, then S must conform to T (S can be provided where an object of type T is expected and correctness is preserved when accessor operation of the object is executed • If S is a subclass of T, doesn’t automatically follow that S is a subtype of T • Any class can be made a structural subclass of another, but it won’t necessarily make sense

26. Invariants, preconditions and postconditions again • Invariants are class level --limit state space. In the geometric library example, a polygon must have 3 or more vertices. • For each of the subtypes of of Polygon, for operations to work, precondition must define vertices and relationships to each other • Postconditions must maintain preconditions + class invariant • So, you won’t end up with the area of a circle from the polygon class or its subtypes

27. Principle of Type Conformance- • Helps avoid problems in class hierarchy • Type of each class should conform to the type of its superclass--this will allow us to effortlessly exploit polymorphism (can pass objects of a subclass in lieu of superclass) • How?

28. Contravariance and Covariance • Every operation’s precondition is no stronger than the corresponding operation in its superclass --principle of contravariance (strength goes in opposite direction from class invariant) • Every operation’s postcondition is at least as strong as the corresponding operation in the superclass (I.e., goes in same direction as class invariant. Operation postconditions get, if anything, stronger) • Gets entertaining when subclass overridesa superclass’s operation with an operation of its own

29. Huh? • Bottom line--hierarchies which obey the contravariance and covariance principles will “work” others will likely crash.

30. Principle of Closed Behavior • Type conformance alone lets us design sound hierarchies, but it leads to sound design decisions only in read-only situations • When modifier operations are executed wealso need the principle of closed behavior--requires that the behavior inherited by a subclass from a superclass should respect the invariant of a subclass. • In practice may mean avoiding inheritance of certain operations or overriding them, reclassify if object as another type if acceptable to application

31. Example • Class Polygon -- operation move applied to subclass triangle -- OK • Class Polygon -- operation addVertex -- operation applied to triangle would make it a rectangle or trapezoid! • Your design must therefore take into consideration the greatest restrain on target’s behavior (lowest class in hierarchy) or restrict polymorphism or check runtime class of target

32. So how does this relate to components • And how do ORBs enter into the soup? • Clearly an ORB influences component type if federate considered a component • How do the principles (connascence, type conformance, contravariance, covariance) apply at this level • Let’s try to apply the principles to federate design and “lower level” components

33. Lightweight and Heavyweight components • Lightweight components utilize classes or components outside of component • Heavy weight components encapsulate everything necessary to do the job • Difference is in degree of encumbrance • Heavy weight components more reusable but harder to understand (also may carry unused code) • HLA components are someplace in between • What would ideal HLA compliant component be?

34. Similarities and differences among components and objects a • components don’t have to be designed or implemented in object-oriented style • different definitions--in some, executables only; some exclude retention of state • different granularity than objects • may be quite large • most useful if same encapsulation and cohesion principles followed as for objects

35. Similarities, Difference, continued • clearly crucial to be able to predict what a component will do • therefore, component must be defined as if object (what it will do--definition, invariants, preconditions, postconditions) but overall • method helpful to allow analysis within encapsulated boundaries (very tricky, even if you develop in very principled manner) • for components to be composable, rules of composition and extension must be developed • TANSTAAFL -- trade offs will have to be made on complexity of interfaces (more complex to be more reusable because of standard interfaces)

36. Implications for Component Design • Rigorous application of design principles • Probably deserves at least a “spiral” devoted to extracting components from original design if not a well understood domain (ie, previously implemented) • CASE tools and design methods which have enough formality for mechanical analysis helpful • Run time analysis of implementations without components would be helpful to determine targets of opportunity