Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The OO Design Principles


Published on

This presentation describe the basic OO design princples, copied from Uncle Bob's S.O.L.I.D princiles and Pragmatic Programmer's DRY, broken window, DBC, LoD.

Published in: Technology

The OO Design Principles

  1. 1. The OO Design Principles Steve Zhang
  2. 2. Introduction <ul><li>Software design definition </li></ul><ul><li>Software nature - entropy </li></ul><ul><li>Discuss Symptoms of poor software design </li></ul><ul><li>Discuss 5 OO software design principles </li></ul><ul><li>Law of Demeter </li></ul><ul><li>Don’t Repeat yourself principle </li></ul><ul><li>Design By Contract </li></ul>
  3. 3. The presentation comes from two books Author: Robert C. Martin Nick Name: Uncle Bob Agile Software Development, principles, patterns and practices
  4. 4. The pragmatic Programmer – from journeyman to master Andy Hunt Dave Thomas
  5. 5. What is Software Design? <ul><li>The source code is the design </li></ul><ul><li>UML diagram represents part of a design, but it is not the design. </li></ul><ul><li>Because the design can only be verified through source code </li></ul><ul><li>The software design process includes coding, testing, refactoring… </li></ul><ul><li>The programmer is real software designer </li></ul>
  6. 6. Software nature – Software entropy <ul><li>Software tends to degrade / decay </li></ul><ul><li>Software rot – like a piece of bad meat </li></ul>
  7. 7. The cost of change curve
  8. 8. Developers productivity vs. time Question: does our project manager consider this curve when doing estimations?
  9. 9. Design Smells – The Odors of Rotting Software <ul><li>Rigidity – The design is hard to change </li></ul><ul><li>Fragility – The design is easy to break </li></ul><ul><li>Immobility – The design is hard to reuse </li></ul><ul><li>Viscosity – It is hard to do the right thing </li></ul><ul><li>Needless complexity – Overdesign </li></ul><ul><li>Needless Repetition – Mouse abuse </li></ul><ul><li>Opacity – Disorganized expression </li></ul>
  10. 10. Rigidity <ul><li>The tendency for software to be difficult to change </li></ul><ul><li>Single change causes cascade of subsequent changes in dependent modules </li></ul><ul><li>The more modules must be changed, the more rigid the design </li></ul>
  11. 11. Fragility <ul><li>The tendency for a program to break in many places when a single changes is made </li></ul><ul><li>The new problems in area that have no conceptual relationship with the area that was changed </li></ul><ul><li>As the fragility of a module increases, the likelihood that a change will introduce unexpected problems approaches certainty. </li></ul>
  12. 12. Immobility <ul><li>Difficult to reuse </li></ul><ul><li>A design is immobile when it contains parts that could be useful in other systems, but the effort and risk involved with separating those parts from the original system are too great. </li></ul><ul><li>This is an unfortunate but very common occurrence. </li></ul>
  13. 13. Viscosity <ul><li>It is easy to do the wrong thing, but hard to do the right thing. </li></ul><ul><li>When the design-preserving methods are more difficult to use than the hacks, the viscosity of the design is high </li></ul><ul><li>When development environment is slow and inefficient, developers will be tempted to do wrong things </li></ul>
  14. 14. Needless complexity <ul><li>Overdesign </li></ul><ul><li>A design smells of needless complexity when it contains elements that aren't currently useful </li></ul><ul><li>The design becomes littered with constructs that are never used </li></ul><ul><li>Makes the software complex and difficult to understand. </li></ul>
  15. 15. Needless Repetition <ul><li>The design contains repeating structures that could be unified under a single abstraction </li></ul><ul><li>The problem is due to developer’s abuse of cut and paste. </li></ul><ul><li>It is really hard to maintain and understand the system with duplicated code. </li></ul>Duplication is Evil! DRY – DON’T REPEAT YOURSELF
  16. 16. Opacity <ul><li>Opacity is the tendency of a module to be difficult to read and understand </li></ul><ul><li>The code does not express its intent well </li></ul><ul><li>The code is written in an opaque and convoluted manner </li></ul>
  17. 17. What Stimulates the Software to Rot? <ul><li>Requirements keep change – design degradation </li></ul><ul><li>People change – violate the original design </li></ul><ul><li>Tight schedule pressure </li></ul><ul><li>Traditional waterfall process can not prevent software from rotting </li></ul><ul><li>Lack of Feedback </li></ul><ul><li>Lack of Communication </li></ul>
  18. 18. The psychology reason – Broken Window Theory <ul><li>Came from city crime researcher </li></ul><ul><li>A broken window will trigger a building into a smashed and abandoned derelict </li></ul><ul><li>So does the software </li></ul><ul><li>Don’t live with the Broken window </li></ul>From the book Pragmatic Programmer – From Journeyman to Master
  19. 19. How can we prevent software from rotting? <ul><li>Applies OO design principles </li></ul><ul><li>Bad design usually violates design principles </li></ul><ul><li>Uses design patterns </li></ul><ul><li>Follows agile practices </li></ul><ul><li>Refactoring will reduce the software entropy </li></ul>
  20. 22. S.O.L.I.D Design Principles <ul><li>SRP – The Single Responsibility Principle </li></ul><ul><li>OCP – The Open-Closed Principle </li></ul><ul><li>LSP – The Liskov Substitution Principle </li></ul><ul><li>ISP – The Interface Segregation Principle </li></ul><ul><li>DIP – The Dependency Inversion Principle </li></ul>
  21. 23. SRP: The Single-Responsibility Principle <ul><li>A class should have only one reason to change. </li></ul><ul><li>If a class has more than one responsibility, then the responsibilities becomes coupled. </li></ul><ul><li>SRP is one of the simplest of the principles, and the one of the hardest to get right. </li></ul>
  22. 24. OCP: The Open-Closed Principle <ul><li>Software entities( classes, modules, functions, etc.) should be open for extension, but closed for modification </li></ul><ul><li>“Open for extension” </li></ul><ul><li>The behavior of the module can be extended </li></ul><ul><li>“Closed for modification” </li></ul><ul><li>Extending the behavior of a module does not resulting changes to the source code or binary code of the module. </li></ul>
  23. 25. OCP – Abstraction is the key Example: Strategy pattern Client is both open and closed
  24. 26. OCP Summary <ul><li>The Open/Closed Principle is at the heart of object-oriented design </li></ul><ul><li>Conformance to OCP is what yields the greatest benefits claimed for object-oriented technology: flexibility, reusability, and maintainability. </li></ul>
  25. 27. Further thinking of OCP <ul><li>Does J2ME preprocess violate OCP or not? </li></ul><ul><li>My answer: Yes </li></ul><ul><li>preprocess itself is anti-OO, give the developer a backdoor to violate OO brutally </li></ul><ul><li>Every time we add a new feature, we have to modify the existing source code </li></ul><ul><li>It is difficult to refactor </li></ul><ul><li>Difficult to reuse, maintain and understand </li></ul><ul><li>So we should be very careful to use preprocess, use it as the last choice instead of the first choice </li></ul><ul><li>> 90% our preprocess code can be removed! </li></ul>
  26. 28. LSP: Liskov Substitution Principle <ul><li>Subtypes must be substitutable for their base types. </li></ul><ul><li>LSP defines the OO inheritance principle. </li></ul><ul><li>If a client uses a base class, then it should not differentiate the base class from derived class, which means the derived class can substitute the base class </li></ul>
  27. 29. LSP violation example: A violation of LSP causing a violation of OCP <ul><ul><li>public enum ShapeType {square, circle}; </li></ul></ul><ul><ul><li>public class Shape{ </li></ul></ul><ul><ul><li>public static void DrawShape(Shape s) { </li></ul></ul><ul><ul><li>if(s.type == ShapeType.square) </li></ul></ul><ul><ul><li>(s as Square).Draw(); </li></ul></ul><ul><ul><li>else if(s.type == </li></ul></ul><ul><ul><li>(s as Circle).Draw(); </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><ul><li>public class Circle : Shape { </li></ul></ul><ul><ul><li>public void Draw() {/* draws the circle */} </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><ul><li>public class Square : Shape{ </li></ul></ul><ul><ul><li>public void Draw() {/* draws the square */} </li></ul></ul><ul><ul><li>} </li></ul></ul>Violate OCP Not substitutable
  28. 30. Another LSP violation example: Rectangle and Square <ul><li>void g(Rectangle r) </li></ul><ul><li>{ </li></ul><ul><li>r.setWidth(5); </li></ul><ul><li>r.setHeight(4); </li></ul><ul><li>if(r.getArea() != 20) </li></ul><ul><li>throw new Exception(&quot;Bad area!&quot;); </li></ul><ul><li>} </li></ul>Square’s behavior is changed, so it is not substitutable to Rectangle IS-A Relationship Square is not Rectangle!
  29. 31. LSP is closely related to Design By Contract methodology <ul><li>A routine re-declaration [in a derivative] may only replace the original precondition by one equal or weaker, and the original post-condition by one equal or stronger. </li></ul><ul><li>Derived classes must accept anything that the base class could accept </li></ul><ul><li>derived classes must conform to all the post-conditions of the base </li></ul>
  30. 32. DIP: The Dependency Inversion Principle <ul><li>High-level modules should not depend on low-level modules. Both should depend on abstractions. </li></ul><ul><li>Abstractions should not depend on details. Details should depend on abstractions. </li></ul><ul><li>DIP is at the very heart of framework design. </li></ul>
  31. 33. A DIP example DIP violation DIP
  32. 34. DIP: an inversion of ownership <ul><li>Inversion is not just one of dependencies, also one of interface ownership. </li></ul><ul><li>Clients own the abstraction interfaces. </li></ul><ul><li>Hollywood principle: “Don’t call us, we’ll call you”. </li></ul>
  33. 35. DIP: Depend on Abstractions <ul><li>No variable should hold a reference to a concrete class. </li></ul><ul><li>No class should derive from a concrete class. </li></ul><ul><li>No method should override an implemented method of any of its base classes. </li></ul>
  34. 36. DIP is also regarded as Dependency Injection & Inversion of Control <ul><li>Dependency injection is the core of the famous Spring framework. </li></ul>
  35. 37. DIP Summary <ul><li>Inversion of dependencies is the hallmark of good object-oriented design. </li></ul><ul><li>If its dependencies are inverted, it has an OO design; if its dependencies are not inverted, it has a procedural design. </li></ul><ul><li>DIP makes abstractions and details isolated from each other, the code is much easier to maintain. </li></ul>
  36. 38. ISP: The Interface Segregation Principle <ul><li>Clients should not be forced to depend on methods they do not use. </li></ul><ul><li>ISP deals with designing cohesive interfaces and avoiding &quot;fat&quot; interfaces. </li></ul><ul><li>The dependency of one class to another one should depend on the smallest possible interface. </li></ul><ul><li>The interfaces of the class can be broken up into groups of methods. </li></ul><ul><li>Each group serves a different set of clients. </li></ul>
  37. 39. An violation of ISP example ISP violation
  38. 40. An ISP Violation example: solution Segregated interface
  39. 41. LoD - Law of Demeter <ul><li>Principle of Least Knowledge </li></ul><ul><li>Only talk to your immediate friends </li></ul><ul><li>Don’t talk to strangers </li></ul><ul><li>Write “shy” codes </li></ul><ul><li>Minimize coupling </li></ul>
  40. 42. LoD formal definition <ul><li>A method M of an object O may only invoke the methods of the following kinds of objects </li></ul><ul><li>O itself </li></ul><ul><li>M's parameters </li></ul><ul><li>any objects created/instantiated within M </li></ul><ul><li>O's direct component objects </li></ul>
  41. 43. LoD
  42. 44. LoD violation example <ul><li>final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath(); </li></ul><ul><li>a.getB().getC().doSomething() </li></ul><ul><li>- Transitive Navigation </li></ul><ul><li>From book Clean Code – A handbook of Agile Software Craftsmanship ( Robert C. Martin) </li></ul>
  43. 45. DRY – Don’t Repeat Yourself <ul><li>Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. </li></ul><ul><li>Following DRY will make software developments easier to understand and maintain </li></ul><ul><li>Duplication is Evil </li></ul>Originated from the book – The pragmatic programmer
  44. 46. How can we prevent duplication? <ul><li>Code duplication – Refactoring code, make it easier to reuse </li></ul><ul><li>Defect duplication – communication, code review, internal forum, internal wiki, and document. </li></ul><ul><li>System design duplication (spec, configuration, deployment, database schema) – keep improving the system design </li></ul><ul><li>Build duplication – build automation </li></ul><ul><li>Use meta programming and code generator technology. </li></ul><ul><li>Duplication is a waste in software development, we need to eliminate the waste </li></ul>
  45. 47. DBC - Design By Contract <ul><li>A contract defines rights and responsibilities between method caller and a routine </li></ul><ul><li>Preconditions – the routine’s requirements, it is the caller’s responsibility to pass the good data </li></ul><ul><li>Postconditions – What the routine is guaranteed to do </li></ul><ul><li>Class invariants – A class ensures that this condition is always true from perspective of a caller </li></ul>
  46. 48. Design By Contract Definition <ul><li>The contract between a routine and any potential caller can thus be read as </li></ul><ul><li> If all the routine’s preconditions are met by the caller, the routine shall guarantee that all posconditions and invariants will be true when it completes. </li></ul>
  47. 49. DBC <ul><li>DBC concept is developed by Betrand Meyer for the language Eiffel. </li></ul><ul><li>We can use assertive programming to implement DBC </li></ul><ul><li>assert(string != null); </li></ul><ul><li>We also use the DBC concept in JUnit test. </li></ul><ul><li>DBC give us a good concept to write a robust software, even java does not support it. </li></ul>
  48. 50. Summary <ul><li>The OO design principles help us: </li></ul><ul><ul><li>As guidelines when designing flexible, maintainable and reusable software </li></ul></ul><ul><ul><li>As standards when identifying the bad design </li></ul></ul><ul><ul><li>As laws to argue when doing code review </li></ul></ul>
  49. 51. References <ul><li>Book - Agile Software Development, Principles, Patterns, and Practices, Robert C. Martin </li></ul><ul><li>Book - Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series) </li></ul><ul><li>Book- The Pragmatic Programmer, </li></ul><ul><li>Article- What is software design? </li></ul><ul><li>Resources from Object Mentor website: </li></ul><ul><li> </li></ul>
  50. 52. Your feedback is very important!
  51. 53. Thank You!