object design principles ii
DESCRIPTION
Object Design Principles II. Elizabeth Bigelow School of Computer Science Carnegie Mellon University. Exam. Will not contain Chapter 12 or Chapter 13 Will primarily test fluency Some interpretation questions Mostly modeling questions Will be long. Packages and Deployment Diagrams. - PowerPoint PPT PresentationTRANSCRIPT
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