Good ObjectOriented Design Principles of HighLevel Design Lecture
Good Object-Oriented Design Principles of High-Level Design Lecture 5 Dr. Radu Marinescu 1
Good Object-Oriented Design High-Level Design § Dealing with large-scale systems 4 > 50 KLOC 4 team of developers, rather than an individual § Classes are a valuable but not sufficient mechanism 4 too fine-grained for organizing a large scale design 4 need mechanism that impose a higher level of order u clusters (Meyer); class-category (Booch); subject-areas (Coad) Packages 4 a logical grouping of declarations that can be imported in other programs (in Java and Ada) 4 containers for a group of classes (UML) u Lecture 5 reason at a higher-level of abstraction Dr. Radu Marinescu 2
Good Object-Oriented Design Issues of High-Level Design Goal 4 partition the classes in an application according to some criteria and then allocate those partitions to packages Issues 4 What are the best partitioning criteria? 4 What principles govern the design of packages? u creation and dependencies between packages 4 Design packages first? Or classes first? u i. e. top-down vs. bottom-up approach Approach 4 Define principles that govern package design u Lecture 5 the creation and interrelationship and use of packages Dr. Radu Marinescu 3
Good Object-Oriented Design Principles of OO High-Level Design § Cohesion Principles 4 Reuse/Release Equivalency Principle (REP) 4 Common Reuse Principle (CRP) 4 Common Closure Principle (CCP) § Coupling Principles 4 Acyclic Dependencies Principle (ADP) 4 Stable Dependencies Principle (SDP) 4 Stable Abstractions Principle (SAP) Lecture 5 Dr. Radu Marinescu 4
Good Object-Oriented Design What is really Reusability ? § Does copy-paste mean reusability? 4 Disadvantage: You own that copy! u u you must change it, fix bugs. eventually the code diverges 4 Maintenance is a nightmare § Martin’s Definition: 4 I reuse code if, and only if, I never need to look at the source-code 4 treat reused code like a product don’t have to maintain it § Clients (re-users) may decide on an appropriate time to use a newer version of a component release Lecture 5 Dr. Radu Marinescu 5
Good Object-Oriented Design Reuse/Release Equivalency Principle (REP) The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused. R. Martin, 1996 § What means this ? 4 A reusable software element cannot really be reused in practice unless it is managed by a release system of some kind u e. g. release numbers or names 4 There is no such thing as ”reusable class” u u without guarantees of notification, safety and support must integrate the entire module (can’t reuse less) Either all the classes in a package are reusable or none of it is! R. Martin, 1996 Lecture 5 Dr. Radu Marinescu 6
Good Object-Oriented Design The Common Reuse Principle All classes in a package [library] should be reused together. If you reuse one of the classes in the package, you reuse them all. R. Martin, Granularity 1996 u u Packages of reusable components should be grouped by expected usage, not by… u … common functionality, nor u … another arbitrary categorization. Classes are usually reused in groups based on collaborations between library classes u e. g. containers and iterators When I depend on a package, I like to depend on every class in that package! Lecture 5 Dr. Radu Marinescu 7
Good Object-Oriented Design Common Closure Principle (CCP) The classes in a package should be closed against the same kinds of changes. A change that affects a package affects all the classes in that package R. Martin, 1996 § What means this ? 4 Classes that change together belong together 4 Goal: limit the dispersion of changes among released packages u u changes must affect the smallest number of released packages relation with OCP 4 Classes within a package must be cohesive 4 Given a particular kind of change, either all classes or no class in a component needs to be modified Lecture 5 Dr. Radu Marinescu 8
Good Object-Oriented Design Reuse vs. Maintenance § REP and CRP makes life easier for reuser 4 packages very small § CCP makes life easier for maintainer 4 large packages § Packages are not fixed in stone 4 early lifetime dominated by CCP 4 later you want to reuse: focus on REP CRP Lecture 5 Dr. Radu Marinescu 9
Good Object-Oriented Design Morning-After Syndrome § You go home and discover the next morning that your stuff is not working anymore… WHY? § Some worked later than you ; -) § Morning-After syndrome 4 Many developers modify the same source files 4 Unable to build a stable version of the system 4 Everyone tries to adapt to the changes that other made § Two solutions 1. Weekly Build 2. Eliminating Dependency Cycles Lecture 5 Dr. Radu Marinescu 10
Good Object-Oriented Design The Weekly Build § Everyone ignores the other for 4 days out of 5 4 Works on private copies of the code § Friday the whole system is integrated § Less feasible as program grows 4 Build flows over in Saturday § …May be it should start already on Thursday 4 Creeps toward the middle of the week § Biweekly build…still not scalable Lecture 5 Dr. Radu Marinescu 11
Good Object-Oriented Design Eliminating Dependency Cycles § Partition work in reusable packages (i. e. units of work) § When a package is working it is release for the others 4 “Users” get notified 4 They can decide if they want to integrate or not u u They choose the integration moment None of the teams is at the mercy of others § One Precondition: there can be no cycles in the package structure! Lecture 5 Dr. Radu Marinescu 12
Good Object-Oriented Design Acyclic Graph of Dependencies § Directed Graph 4 Arrows indicate who depends on whom § When My. Dialogs changes only a few other packages are affected § When My. Dialogs is tested, it depends only on Windows § Release of the whole system bottom-up Lecture 5 Dr. Radu Marinescu 13
Good Object-Oriented Design Cyclic Dependencies Lecture 5 Dr. Radu Marinescu 14
Good Object-Oriented Design Acyclic Dependencies Principles (ADP) The dependency structure for released component must be a Directed Acyclic Graph (DAG) There can be no cycles. R. Martin, 1996 Lecture 5 Dr. Radu Marinescu 15
Good Object-Oriented Design Breaking the Cycles Lecture 5 Dr. Radu Marinescu 16
Good Object-Oriented Design “Copy” Program Revisited class Reader { public: virtual int read()=0; }; Copy Reader Writer Keyboard Reader Printer Writer class Writer { public: virtual void write(int)=0; }; Disk Writer void Copy(Reader& r, Writer& w){ int c; while((c = r. read()) != EOF) w. write(c); } Why are these dependencies good? (better than earlier) Lecture 5 Dr. Radu Marinescu 17
Good Object-Oriented Design Good Dependencies § Targets of unavoidable dependencies are non-volatile 4 unlikely to change 4 e. g. Reader and Writer classes have a low volatility the Copy class is “immune” to changes A “Good Dependency” is a dependency upon something with low volatility. Lecture 5 Dr. Radu Marinescu 18
Good Object-Oriented Design Volatility and Stability Volatility Factors 4 hard-coding of improper information u e. g. print version number 4 market pressure 4 whims of customers § Volatility is difficult to understand predict Stability 4 defined as “not easily moved” 4 a measure of the difficulty in changing a module u not a measure of the likelihood of a change 4 modules that are stable are going to be less volatile u e. g. Reader and Writer classes are stable Stability = Responsibility + Independence Lecture 5 Dr. Radu Marinescu 19
Good Object-Oriented Design Stability Metrics § Afferent Coupling (Ca) 4 number of classes outside this package that depend upon the measured package u "how responsible am I? " (FAN-IN) § Efferent Coupling (Ce) 4 number of classes outside this package that classes within the measured package depend on u "how dependent am I ? " (FAN-OUT) § Instability Factor (I) 4 I [0, 1] 4 0 = totally stable; 1 = totally unstable Lecture 5 Dr. Radu Marinescu 20
Good Object-Oriented Design Computing Stability Metrics Ca = 4 Ce = 3 I=3/6 Lecture 5 Dr. Radu Marinescu 21
Good Object-Oriented Design Stable Dependencies Principle (SDP) The dependencies between components in a design should be in the direction of stability. A component should only depend upon components that are more stable than it is. R. Martin, 1996 Depend only upon components whose I metric is lower than yours R. Martin, 1996 SDP Violation Lecture 5 Dr. Radu Marinescu 22
Good Object-Oriented Design Where to Put High-Level Design? § High-level architecture and design decisions don't change often 4 shouldn't be volatile place them in stable packages 4 design becomes hard to change inflexible design § How can a totally stable package (I = 0) be flexible enough to withstand change? 4 improve it without modifying it. . . § Answer: The Open-Closed Principle 4 classes that can be extended without modifying them Abstract Classes Lecture 5 Dr. Radu Marinescu 23
Good Object-Oriented Design Stable Abstractions Principle (SAP) The abstraction of a package should be proportional to its stability! Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. R. Martin, 1996 § Ideal Architecture 4 Instable (changeable) packages on the top u must be concrete 4 Stable (hard to change) package on the bottom u u u hard to change, but easy to extend highly abstract (easily extended) Interfaces have more intrinsic stability than executable code § SAP is a restatement of DIP Lecture 5 Dr. Radu Marinescu 24
Good Object-Oriented Design Measuring Abstraction § Abstraction of a Package 4 A [0, 1] 4 0 = no abstract classes 4 1 = all classes abstract § Metric A is imperfect, but usable 4 hybrid classes are also counted as abstract uincluding pure virtual functions § Alternative 4 find a metric based on the ratio of virtual functions Lecture 5 Dr. Radu Marinescu 25
Good Object-Oriented Design The Main Sequence Instability (I) should increase as abstraction (A) decreases. R. Martin, 2000 Lecture 5 Dr. Radu Marinescu 26
Good Object-Oriented Design Main Sequence (contd. ) § Zone of Pain 4 highly stable and concrete rigid 4 famous examples: u u database-schemas (volatile and highly depended-upon) concrete utility libraries (instable but non-volatile) § Zone of Uselessness 4 instable and abstract useless u no one depends on those classes § Main Sequence 4 maximizes the distance between the zones we want to avoid 4 depicts the balance between abstractness and stability. Lecture 5 Dr. Radu Marinescu 27
Good Object-Oriented Design Measurement of OO Architectures § Distance 4 ranges from [0, ~0. 707] § Normalized Distance 4 ranges from [0, 1] 4 0 = package on the main sequence 4 1 = package far away from main seq. Lecture 5 Dr. Radu Marinescu 28
- Slides: 28