! Needles Complexity! make design more general than needed " e.g. interfaces and/or abstract classes with just one implementor

Transcription

1 Bibliography Principles and Rules of Object-Oriented Design Dr. Radu Marinescu 67 Dr. Radu Marinescu 68 Signs of Rotting Design [Martin, 2002]! Rigidity! code difficult to change (Continuity)! management reluctance to change anything becomes policy! Fragility! code breaks in unexpected places (Protection)! even small changes can cause cascading breaks! Immobility! code is so tangled that it's impossible to reuse anything (Composability) " lots of semantical (or even syntactical) duplication! Viscosity! much easier to hack than to preserve original design " easy to do the wrong thing, but hard to do the right thing (R.Martin)! software viscosity and environment viscosity Dr. Radu Marinescu 69 Signs of Rotting Design (2) [Martin, 2002]! Needles Complexity! make design more general than needed " e.g. interfaces and/or abstract classes with just one implementor! constructs and mechanisms that are never used! Needles Repetition! copy-paste-adapt " bugs are cloned as well! sign of a missing abstraction! Opacity! convoluted manner of writing code (hampers understandability)! pair-programming and refactoring may help fighting against opaque code Dr. Radu Marinescu 70

2 Causes of Rotting Design 1. Changing Requirements! is inevitable! both better designs and poor designs have to face the changes;! good designs are stable All systems change during their life-cycles. This must be borne in mind when developing systems expected to last longer than the first version. I. Jacobson, OOSE, 1992 Read Keyboard Copy Example of Rigidity and Immobility Write Disk Write Printer enum OutputDevice {printer, disk; void Copy(OutputDevice dev){ int c; while((c = ReadKeyboard())!= EOF) if(dev == printer) WritePrinter(c); else WriteDisk(c); 2. Dependency Management! the issue of coupling and cohesion! It can be controlled! " create dependency firewalls Dr. Radu Marinescu 71 void Copy(){ int c; while ((c = ReadKeyboard())!= EOF) WritePrinter(c); Dr. Radu Marinescu 72 Open-Closed Principle (OCP) Software entities should be open for extension, but closed for modification B. Meyer, 1988 / quoted by R. Martin, 1996 Open the door...! Be open for extension! module's behavior can be extended! Be closed for modification! source code for the module must not be changed Modules should be written so they can be extended without requiring them to be modified How to make the Car run efficiently with a TurboEngine? Only by changing the Car!...in the given design Dr. Radu Marinescu 73 Dr. Radu Marinescu 74

3 ... But Keep It Closed! OCP Heuristics RTTI is Ugly and Dangerous!! A class must not depend on a concrete class!! It must depend on an abstract class......using polymorphic dependencies (calls)! RTTI is ugly and dangerous! RTTI = Run-Time Type Information! If a module tries to dynamically cast a base class pointer to several derived classes, any time you extend the inheritance hierarchy, you need to change the module! recognize them by type switch or if-else-if structures! Not all these situations violate OCP all the time! when used only as a "filter" Dr. Radu Marinescu 75 Dr. Radu Marinescu 76 Reader Keyboard Reader Copy Writer Printer Writer OCP Applied on Example Disk Writer class Reader { public: virtual int read()=0; ; class Writer { public: virtual void write(int)=0; ; void Copy(Reader& r, Writer& w){ int c; while((c = r.read())!= EOF) w.write(c); What if we decide to change that only each second character is written? Strategic Closure No significant program can be 100% closed! Closure not complete but strategic 1. Abstraction to gain explicit closure! provide class methods which can be dynamically invoked " to determine general policy decisions! design using abstract ancestor classes 2. Use "Data-Driven" approach to achieve closure! place volatile policy decisions in a separate location " e.g. a file or a separate object! minimizes future change locations R.Martin Dr. Radu Marinescu 77 Dr. Radu Marinescu 78

4 Use Abstract to Gain Closure [Martin, 2002] Data-Driven Approach to Get Closure [Martin, 2002] public interface Shape : IComparable{ void Draw(); public class Circle : Shape { public int CompareTo(object o){ if(o is Square) return -1; else return 0; Not Closed anymore to adding new Shapes! public void DrawAllShapes(ArrayList shapes) { shapes.sort(); foreach(shape shape in shapes) shape.draw(); public class ShapeComparer : IComparer { private static Hashtable priorities = new Hashtable(); static ShapeComparer() { priorities.add(typeof(circle), 1); priorities.add(typeof(square), 2); private int PriorityFor(Type type) { if(priorities.contains(type)) return (int)priorities[type]; else return 0; Dr. Radu Marinescu 79 Dr. Radu Marinescu 80 Data-Driven Approach to Get Closure (2) [Martin, 2002] Procedural Architecture is Top-Down public int Compare(object o1, object o2) { int priority1 = PriorityFor(o1.GetType()); int priority2 = PriorityFor(o2.GetType()); return priority1.compareto(priority2); Procedural Architecture public void DrawAllShapes(ArrayList shapes) { shapes.sort(new ShapeComparer()); foreach(shape shape in shapes) shape.draw(); Dr. Radu Marinescu 81 Dr. Radu Marinescu 82

5 Dependency Inversion Principle I. High-level modules should not depend on low-level modules. Both should depend on abstractions. II. Abstractions should not depend on details. Details should depend on abstractions R. Martin, 1996 Procedural Architecture Procedural vs. OO Architecture! Corrolar 1: A base class in an inheritance hierarchy should not know any of its subclasses! Corrolar 2: Modules with detailed implementations are not depended upon, but depend themselves upon abstractions! OCP states the goal; DIP states the mechanism; Object-Oriented Architecture Dr. Radu Marinescu 83 Dr. Radu Marinescu 84 DIP Related Heuristic Design to an interface, not an implementation! Design to an Interface! Abstract classes/interfaces:! tend to change less frequently! abstractions are hinge points where it is easier to extend/modify! shouldn t have to modify classes/interfaces that represent the abstraction (OCP)! Use inheritance to avoid direct bindings to classes: Client Interface (abstract class) Implementation (concrete class)! Exceptions! Some classes are very unlikely to change; " therefore little benefit to inserting abstraction layer " Example: String class! In cases like this can use concrete class directly " as in Java or C++ Dr. Radu Marinescu 85 Dr. Radu Marinescu 86

6 DIP Related Heuristic (2) Avoid Transitive Dependencies Solution to Transitive Dependencies! Use inheritance and abstract ancestor classes to effectively eliminate transitive dependencies:! also a matter of interface ownership! Avoid structures in which higher-level layers depend on lower-level abstractions:! In example below, Policy layer is ultimately dependent on Utility layer. Policy Layer depends on Policy Service Interface Policy Layer depends on Mechanism Layer depends on Utility Layer Mechanism Layer depends on Mechanism Service Interface Utility Layer Dr. Radu Marinescu 87 Dr. Radu Marinescu 88 DIP - Related Heuristic When in doubt, add a level of indirection! If you cannot find a satisfactory solution for the class you are designing, try delegating responsibility to one or more classes: When in doubt...! It is generally easier to remove or by-pass existing levels of indirection than it is to add them later: Blue class s indirect message calls to red class fail to meet some criteria (e.g. real-time constraints, etc.) Problem Holder Problem Solver So, Blue class re-implements some or all of green class s responsibilities for efficiency and calls red object directly X Dr. Radu Marinescu 89 Dr. Radu Marinescu 90

7 LSP and Replaceability Any code which can legally call another class s methods must be able to substitute any subclass of that class without modification: Liskov Substitution Principle Client Service Class Client Service Class Unexpected Subclass Dr. Radu Marinescu 91 Dr. Radu Marinescu 92 Liskov Substitution Principle (LSP)! The key of OCP: Abstraction and Polymorphism! Implemented by inheritance! How do we measure the quality of inheritance? Inheritance should ensure that any property proved about supertype objects also holds for subtype objects B. Liskov, 1987 Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. R. Martin, 1996 LSP is about Semantics and Replacement! Understand before you design! The meaning and purpose of every method and class must be clearly documented! Lack of user understanding will induce de facto violations of LSP! Replaceability is crucial! Whenever any class is referenced by any code in any system, any future or existing subclasses of that class must be 100% replaceable! Because, sooner or later, someone will substitute a subclass; " it s almost inevitable. Dr. Radu Marinescu 93 Dr. Radu Marinescu 94

8 Inheritance Appears Simple class Bird { // has beak, wings,... public void fly() {... // Bird can fly class Parrot : public Bird { // Parrot is a bird public void mimic() {... // Can Repeat words... public void fly() {... // Parrots fly in a specific way ; //... Parrot mypet; mypet.mimic(); mypet.fly(); // my pet being a parrot can Mimic() // my pet is-a bird, can fly Penguins Fail to Fly! class Penguin extends Bird { public void fly() { error ( Penguins don t fly! ); void PlayWithBird (Bird abird) { abird.fly(); // OK if Parrot. // if bird happens to be Penguin...OOOPS!!! Does not model: Penguins can t fly. It models Penguins may fly, but if they try it is error! Run-time error if attempt to fly! not desirable! Think about Substitutability - Fails LSP Dr. Radu Marinescu 95 Dr. Radu Marinescu 96 Design by Contract! Advertised Behavior of an object:! advertised Requirements (Preconditions)! advertised Promises (Postconditions) When redefining a method in a derivate class, you may only replace its precondition by a weaker one, and its postcondition by a stronger one B. Meyer, 1988 Derived class services should require no more and promise no less int Base::f(int x); // REQUIRE: x is odd // PROMISE: return even int int Derived::f(int x); // REQUIRE: x is int // PROMISE: return 8 Design by Contract! Impose a certain obligation to be guaranteed on entry by any client module that calls it: the routine's precondition! Guarantee a certain property on exit: the routine's postcondition! Maintain a certain property, assumed on entry and guaranteed on exit: the class invariant! What does it expect?! What does it guarantee?! What does it maintain? Dr. Radu Marinescu 97 Dr. Radu Marinescu 98

9 Square IS-A Rectangle? Square The Answer is...! Override setheight and setwidth! duplicated code...?! The real problem void g(rectangle& r) { r.setwidth(5); r.setheight(4); // How large is the area?! 20!... Are you sure? ;-)! Should I inherit Square from Rectangle? Dr. Radu Marinescu 99 IS-A relationship refers to the BEHAVIOR of the class! Dr. Radu Marinescu 100 LSP Related Heuristic (2) It is illegal for a derived class, to override a base-class method with a NOP method! NOP = a method that does nothing! Solution 1: Inverse Inheritance Relation! if the initial base-class has only additional behavior " e.g. Dog - DogNoWag! Solution 2: Extract Common Base-Class! if both initial and derived classes have different behaviors! for Penguins! Birds, FlyingBirds, Penguins! Classes with bad state! e.g. stupid or paralyzed dogs... Single Responsibility Principle (SRP) A class should have only one reason to change!! A Responsibility is a reason to change! Single Responsibility = increased cohesion! Not following results in needless dependencies! More reasons to change.! Rigidity, Immobility! Can be tricky to get granularity right R. Martin Dr. Radu Marinescu 101 Dr. Radu Marinescu 102

10 When SRP is violated...! The Rectangle has 2 responsibilities... due to the various clients When SRP is considered...! The bad part: ComputationalGeometryApplication depends now on GUI! could be either aggregation or inheritance! Dr. Radu Marinescu 103 Dr. Radu Marinescu 104 Common Violation of SRP! mix business rules and persistence control! should almost never be mixed! business rules change often ; persistency rules change sometimes but always for different reasons Clients should depend on slim interfaces... Dr. Radu Marinescu 105 Dr. Radu Marinescu 106

11 Interface Segregation Principle ISP Example Clients should not be forced to depend upon interfaces that they do not use. R. Martin, 1996! Door and Timed Door! lock(), unlock(), isopen()! TimedDoor beeps when door is open for too long Timer TimerClient 0..* Naïve!! Many client-specific interfaces are better than one general purpose interface Door! Consequence:! impact of changes to one interface aren t as big if interface is smaller! interface pollution clas Timer { public void register(int timeout, TimerClient cl); // ; interface TimerClient { void OnTimeOut()=0; TimedDoor Dr. Radu Marinescu 107 Dr. Radu Marinescu 108 What Can Happen?! What if......i close the door before the timeout and then open it again? :)) Separation through Multiple Interfaces! in fact implementation of multiple interfaces -> we need to identify the timeout request -> change affects the interface of TimerClient -> all clients get affected! public class Timer { public void Register(int timeout, int timeoutid, TimerClient client) {/*code*/ public interface TimerClient { void TimeOut(int timeoutid); Why should a Door subclass, that is not related to timing be affected by this change?!! Dr. Radu Marinescu 109 Dr. Radu Marinescu 110

12 Separation Through Delegation Timer 0..* TimerClient Door +ontimeout() DoorTimer Adapter thetimeddoor <<creates>> TimedDoor +reactontimeout() Rela!ii intre Clase si Obiecte ontimeout(...) { thetimeddoor.reactontimeout(...); Dr. Radu Marinescu 111 Dr. Radu Marinescu 112 Implementare Relatiei USES Prin Continere 1. Continere 2. Referinta 3. Mapare 4. Parametrii 5. Prin Constructie (Locala) 6. Prin Date Globale Prin Referinta Oracolul din Delfi ii spune cine e obietul cu care sa comunice Dr. Radu Marinescu 113 Dr. Radu Marinescu 114

13 Prin Mapper Prin Constructie Prin Parametri Prin Date Globale Dr. Radu Marinescu 115 Dr. Radu Marinescu 116 Ce conteaza cand e vorba de cuplaj? Exercitiu: In care din urmatoarele situatii cuplajul este mai redus? X Y Shy Code [PragmaticProgrammer99]! Spy, dissidents and revolutionaries! eliminating interactions protects anyone! The General contractor example! he must manage subcontractors f11() f12() f13() f11() f12() f13() Cati apeleaza? (Impact Eroare Unica)! Don't reveal yourself to others! Information Hiding modularization rule! Don't interact with too many people! Few Interfaces modularization rule Cati sunt apelati? (Impact Decuplare, Probabilitate Eroare) Dr. Radu Marinescu 117 Dr. Radu Marinescu 118

14 Law of Demeter! Weak Form Inside of a method M of a class C, data can be accessed in and messages can be sent to only the following objects:! this and super! data members of class C! parameters of the method M! object created within M " by calling directly a constructor " by calling a method that creates the object! global variables! Strong Form: In addition to the Weak Form, you are not allowed to access directly inherited members Dr. Radu Marinescu 119 class Demeter { private: A *a; public: // void example(b& b); void Demeter::example(B& b) { C c; func(); b.invert(); a = new A(); a->setactive(); c->print(); Demeter s Law on Example Any methods of an object should call only methods belonging to: itself passed parameters created objects directly held component objects Dr. Radu Marinescu 120 class Course { Instructor boring = new Instructor(); int pay = 5; public Instructor getinstructor() { return boring; public Instructor getnewinstructor() {return new Instructor(); public int getpay() {return pay; class C { Course test = new Course(); Example of LoD Violation public void badm() { test.getinstructor().fired(); public void goodm() { test.getnewinstructor().hired(); class Course { Instructor boring = new Instructor(); int pay = 5; public Instructor fireinstructor() { boring.fired(); public Instructor getnewinstructor() { return new Instructor(); public int getpay() { return pay ; class C { Course test = new Course(); How to eliminate the LoD violation? public void reformedbadm() { test.fireinstructor(); public void goodm() { test.getnewinstructor().hired(); public int goodorbadm?() { return test.getpay() + 10; public int goodorbadm() { return test.getpay() + 10; Dr. Radu Marinescu 121 Dr. Radu Marinescu 122

15 Breaking News Dr. Radu Marinescu 123 Dr. Radu Marinescu 124 The Law of Demeter for Children ;-)! You can play with yourself.! You can play with your own toys, but you can't take them apart! You can play with toys that were given to you.! You can play with toys you've made yourself. Benefits of Demeter s Law! Coupling Control! reduces data coupling! Information hiding! prevents from retrieving subparts of an object! Information restriction! restricts the use of methods that provide information! Experimental study [Basili et al., TSE, 1996] suggest that the Law of Demeter is a valid way to reduce the probability of software faults. Dr. Radu Marinescu 125 Dr. Radu Marinescu 126

16 Acceptable LoD Violations Euristici Legate De Cuplaj! If optimization requires violation! Speed or memory restrictions! Make a distinction between objects and data structures! If module accessed is a fully stabilized black box! No changes to interface can reasonably be expected due to extensive testing, usage, etc. Reduceti numarul claselor de care depinde fiecare clasa! Reduceti numarul de metode distincte apelate dintr-o clasa data! Reduceti numarul de apeluri catre alte clase pentru o clasa data!!...otherwise, do not violate this law!!! Long-term costs will be very prohibitive Dr. Radu Marinescu 127 Dr. Radu Marinescu 128 Relatia de CONTINERE (CONTAINMENT) Care clasa ai prefera sa o utilizezi? Daca o clasa, contine obiecte ale altei clase, atunci clasa care contine obiectele trebuie sa foloseasca acele obiecte. Ea si numai ea!... altfel relatia de continere e falsa!! fie clasa care contine nu are nevoie de respectivele date! fie ele sunt plasate gresit (daca sunt folosite mai mult de catre o alta clasa). A B NU CONTEAZA! Dr. Radu Marinescu 129 Dr. Radu Marinescu 130

17 Care clasa ai prefera sa o implementezi? Forma ideala a ierarhiilor de continere B Organizati relatii de continere in ierarhii adanci si inguste A Majoritate metodelor unei clase ar trebui sa foloseasca majoritatea datelor clasei!... pentru ca nu mai accesam datele partilor ci identificam servicii ale acestora! castigam flexibilitatea # modalitati multiple de reutilizare! In general ar fi bine ca o clasa sa nu contina mai mult de 6 obiecte ca atribute! Ce se intampla daca doar cateva metode folosesc majoritatea datelor? ;-) Dr. Radu Marinescu 131 Dr. Radu Marinescu 132 Constrangeri Semantice... adica ce ne facem daca avem limitari in privinta compunerii felurilor de mancare? $! Solutia I! nu las sa se construiasca obiectul! constrangerea semantica este plasata in constructorul obiectul care agrega Principles of High-Level Design! Solutia II! constructorul permitea construirea unor obiecte ilegale! testarea se face la nivelul metodelor care folosesc obiectul... o sa vedeti voi cand vorbim despre Composite ;-) Dr. Radu Marinescu 133 Dr. Radu Marinescu 134

18 High-Level Design! Dealing with large-scale systems! > 50 KLOC! team of developers, rather than an individual! Classes are a valuable but not sufficient mechanism! too fine-grained for organizing a large scale design! need mechanism that impose a higher level of order " clusters (Meyer); class-category (Booch); subject-areas (Coad) Packages! a logical grouping of declarations that can be imported in other programs (in Java and Ada)! containers for a group of classes (UML) " reason at a higher-level of abstraction Issues of High-Level Design Goal!partition the classes in an application according to some criteria and then allocate those partitions to packages Issues! What are the best partitioning criteria?! What principles govern the design of packages? " creation and dependencies between packages! Design packages first? Or classes first? " i.e. top-down vs. bottom-up approach Approach!Define principles that govern package design " the creation and interrelationship and use of packages Dr. Radu Marinescu 135 Dr. Radu Marinescu 136! Acyclic Dependencies Principle (ADP)! Stable Dependencies Principle (SDP)! Stable Abstractions Principle (SAP) Coupling Principles of OO HLD 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! Many developers modify the same source files! Unable to build a stable version of the system! Everyone tries to adapt to the changes that other made! Two solutions 1. Weekly Build 2. Eliminating Dependency Cycles Dr. Radu Marinescu 137 Dr. Radu Marinescu 138

19 The Weekly Build! Everyone ignores the other for 4 days out of 5! Works on private copies of the code! Friday the whole system is integrated! Less feasible as program grows! Build flows over in Saturday! May be it should start already on Thursday! Creeps toward the middle of the week Eliminating Dependency Cycles! Partition work in reusable packages (i.e. units of work)! When a package is working it is released for the others! Users get notified!they can decide if they want to integrate or not " 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!! Bi-weekly build still not scalable Dr. Radu Marinescu 139 Dr. Radu Marinescu 140 Acyclic Graph of Dependencies! Directed Graph! Arrows indicate who depends on whom Cyclic Dependencies! When MyDialogs changes only a few other packages are affected! When MyDialogs is tested, it depends only on Windows! Release of the whole system bottom-up Dr. Radu Marinescu 141 Dr. Radu Marinescu 142

20 Acyclic Dependencies Principles (ADP) Breaking the Cycles The dependency structure for released component must be a Directed Acyclic Graph (DAG) There can be no cycles. R. Martin, 1996 Dr. Radu Marinescu 143 Dr. Radu Marinescu 144 Reader Keyboard Reader Copy Copy Program Revisited Writer Printer Writer Disk Writer class Reader { public: virtual int read()=0; ; class Writer { public: virtual void write(int)=0; ; void Copy(Reader& r, Writer& w){ int c; while((c = r.read())!= EOF) w.write(c); Why are these dependencies good? (better than earlier) Good Dependencies! Targets of unavoidable dependencies are non-volatile! unlikely to change! 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. Dr. Radu Marinescu 145 Dr. Radu Marinescu 146

21 Stability! defined as not easily moved! a measure of the difficulty in changing a module! not a measure of the likelihood of a change! Responsibility = how many depend on a module?! Autonomy = on how many does a module depend? Stability = Responsibility + Autonomy Stability Metrics! Afferent Coupling (C a )!number of classes outside this package that depend upon the measured package " "how responsible am I?" (FAN-IN)! Efferent Coupling (C e )!number of classes outside this package that classes within the measured package depend on " "how dependent am I?" (FAN-OUT)! Instability Factor (I)! I # [0, 1]! 0 = totally stable; 1 = totally unstable Dr. Radu Marinescu 147 Dr. Radu Marinescu 148 Computing Stability Metrics Ca = 4 Ce = 3 I = 3 / 7 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 Dr. Radu Marinescu 149 Dr. Radu Marinescu 150

22 Where to Put High-Level Design?! High-level architecture and design decisions don't change often! shouldn't be volatile " place them in stable packages! design becomes hard to change " inflexible design! How can a totally stable package (I = 0) be flexible enough to withstand change?! improve it without modifying it...! Answer: The Open-Closed Principle! classes that can be extended without modifying them " Abstract Classes Stable Abstractions Principle (SAP) The abstraction of a package should be proportional to its stability! Packages that are maximally stable should be maximally abstract. Unstable packages should be concrete. R. Martin, 1996! Ideal Architecture!Unstable (changeable) packages on the top " must be concrete!stable (hard to change) package on the bottom " 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 Dr. Radu Marinescu 151 Dr. Radu Marinescu 152! Abstraction of a Package! A # [0, 1]! 0 = no abstract classes! 1 = all classes abstract Measuring Abstraction The Main Sequence! Metric A is imperfect, but usable!hybrid classes are also counted as abstract "including pure virtual functions! Alternative!find a metric based on the ratio of virtual functions Instability (I) should increase as abstraction (A) decreases. R. Martin, 2000 Dr. Radu Marinescu 153 Dr. Radu Marinescu 154

23 Main Sequence (contd.)! Zone of Pain! highly stable and concrete " rigid! famous examples: " database-schemas (volatile and highly depended-upon) " concrete utility libraries (unstable but non-volatile)! Zone of Uselessness! unstable and abstract " useless " no one depends on those classes! Main Sequence! maximizes the distance between the zones we want to avoid! depicts the balance between abstractness and stability.! Distance! Normalized Distance Measurement of OO Architectures!ranges from [0, ~0.707]!ranges from [0, 1]! 0 = package on the main sequence! 1 = package far away from main seq. Dr. Radu Marinescu 155 Dr. Radu Marinescu 156