Object Design Principles II

Elizabeth BigelowSchool of Computer ScienceCarnegie Mellon University

Exam

Will not contain Chapter 12 or Chapter 13Will primarily test fluencySome interpretation questionsMostly modeling questionsWill be long

Packages and DeploymentDiagrams

Packages used to simplify diagramsDependencies are most common association between packages—used for analysis for where they can be reduced or where changes should be madeMany people use packages for components in deployment diagramsNote that all contents should be within a “node” on a deployment diagram. Packages allow you to do this

Basic Design Questions

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

Golden Rules of Object (or most any other design)

Minimize couplingIncrease cohesion

& so what anyhow?

Increase in maintainability, understandabilityrobustness (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 designremember: 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

Examples

Dogs and Owners Which design is best and why?

Geometric Library What could go wrong when you

invoke operations?

Domains

Domain used slightly differently here--groups of classesFoundation, Architecture, Business, Application

Foundation

useful across all businesses and architectures(semantic,structural, fundamental)Date,Time, Angle, MoneyStack, Queue, BinaryTree, SetInteger, Boolean, CharDon’t do these at home!

Architecture

Classes valuable for one implementation architectureHuman-interface classes (Window, CommandButton)Database-manipulation classes (Transaction, Backup)Machine-communication classes (Port, RemoteMachine)

Business Classes

Useful for one industry or companyRelationship classes (AccountOwnership for bank, Patient Supervision for hospital nurse)Role classes (Customer, Patient)Attribute classes (properties of things--Balance, BodyTemperature)

Application

Classes valuable for one applicationEvent recognizer classes (event daemons, PatientTemperatureMonitor)Event manager classes (carry out business policy--WarmHypothermicPatient)

Where do we get classes for each domain

Foundation -buyArchitectural--buy from vendors of hardware or software infrastructure--need tailoring for compatibility with foundation classesBusiness--usually have to build; changing a bit with movement to componentsApplication--almost always have to build

Encumbrance

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

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

More Intuitively (:-) )

C

C1 C2 C3

C

C1 C2 C3

c11 c12 c21 c22 c31 c32

F1 F2 F3 F4 F5

Direct ClassReference SetEncumbrance = 3

Indirect Class Reference SetEncumbrance = 13

Concrete Example

Rectangle 4

Point 3

Length 2

Boolean 0 Real 0

Numbers are indirect encumbrance

Use of encumbrance

Measure of class sophistication--how high the class is above the fundamental domainClasses in higher domains have high indirect encumbrance and those in lower, low indirect encumbranceUnexpected indirect encumbrance may indicate fault in class design--high indirect encumbrance in a low domain, there may be a fault in class cohesionIf class in high domain has low indirect encumbrance, probably designed from scratch rather than reusing intermediate classes from library

Law of Demeter

Strong law--variable can only be a variable defined in a class itselfWeak law --defines variable as being either a variable of the class or one it inherits from its superclass

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

So what?

Frees designer of C’s superclasses to redesign their internal implementationEnhances 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 classMinimizes connascence across encapsulation boundaries

Class cohesionClass cohesion is the measure of how well the features of the class (operatiions and attributes) belong together in a single classMixed-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 domainTry these concepts against the dog owner handouts

So?Mixed-instance cohesion results in greatest design and maintenance problemsMixed-role cohesion tends to result in fewest problemsClasses 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.

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

Remember subtypes? Subclasses?

Subclass is distinct from subtypeIf 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 executedIf S is a subclass of T, doesn’t automatically follow that S is a subtype of TAny class can be made a structural subclass of another, but it won’t necessarily make sense

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 otherPostconditions must maintain preconditions + class invariantSo, you won’t end up with the area of a circle from the polygon class or its subtypes

Principle of Type Conformance-

Helps avoid problems in class hierarchyType 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?

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 overrides a superclass’s operation with an operation of its own

Huh?

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

Principle of Closed Behavior

Type conformance alone lets us design sound hierarchies, but it leads to sound design decisions only in read-only situationsWhen 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

Example

Class Polygon -- operation move applied to subclass triangle -- OKClass 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

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 levelLet’s try to apply the principles to federate design and “lower level” components

Lightweight and Heavyweight components

Lightweight components utilize classes or components outside of componentHeavy weight components encapsulate everything necessary to do the jobDifference is in degree of encumbranceHeavy 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?

Similarities and differences among components and objects a

components don’t have to be designed or implemented in object-oriented styledifferent definitions--in some, executables only; some exclude retention of statedifferent granularity than objectsmay be quite largemost useful if same encapsulation and cohesion principles followed as for objects

Similarities, Difference, continued

clearly crucial to be able to predict what a component will dotherefore, component must be defined as if object (what it will do--definition, invariants, preconditions, postconditions) but overallmethod 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 developedTANSTAAFL -- trade offs will have to be made on complexity of interfaces (more complex to be more reusable because of standard interfaces)

Implications for Component Design

Rigorous application of design principlesProbably 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 helpfulRun time analysis of implementations without components would be helpful to determine targets of opportunity