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
  packagesused 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, well 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 youre
  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
• Dont 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 from scratch
  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 ops
  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 Cs superclasses to redesign
  their internal implementation
• Enhances understandability of C, because someone
  trying to understand the design of C isnt
  continually dragged into the implementation
  details of Cs 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, doesnt automatically
  follow that S is a subtype of T
• Any class can be made a structural subclass of
  another, but it wont 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 wont 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 operations precondition is no stronger
  than the corresponding operation in its
  superclass --principle of contravariance
  (strength goes in opposite direction from class
  invariant)
• Every operations 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 overrides a
  superclasss 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 targets
  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
• Lets 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 dont 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