Object-oriented design principles
- 1. Object Oriented Design Principles –– class level Xiao-Yan Chen Beijing/July 13, 2007
- 2. 2 Agenda > Introduction > OO Design Principles > Evil Stuff and Anti-Patterns
- 3. 3 Introduction > Where we are? Methodology and Design Tech Process Tools Methodology Design technique Heavyweight process Agile process Process appraisal and improvement For supporting process For supporting methodology For supporting Design technique
- 4. 4 Principles > What is a bad design? > The principles • OCP open-closed principle • SRP single responsibility principle • ISP interface segregation principle • LSP Liskov substitution principle • DIP dependency inversion principle > Principles reviewed
- 5. 5 Bad designs > Rigidity – hard to change > Fragility – easy to break > Immobility – hard to reuse > Viscosity – hard to do the right thing > Needless Complexity – over design > Needless Repetition – error prone > Opacity – hard to read and understand
- 6. 6 Open Closed Principle > Examples of OCP violation public interface Shape extends Comparable{ public void draw(); } public class Circle implements Shape { public void draw() { } public int compareTo(Object o) { if (o instanceof Rectangel) { return -1; } else if (o instanceof Circle) { return 0; } else { return 1; } } } Shape Circle Rectangle New Shape
- 7. 7 Open Closed Principle Software entities should be open for extension, but closed for modification B. Meyer, 1988 > Be open for extension • module's behavior can be extended > Be closed for modification • source code for the module must not be changes > Modules should be written so they can be extended without requiring them to be modified
- 8. 8 Open Closed Principle > How to: • Encapsulate what varies. • Abstraction is the KEY. • Use “Data-Driven” approaches. > This principle implies that: • Make all member variables private. • No global variables. • RTTI (Run-Time Type Information) is dangerous. > Also: • No significant program can be 100% closed. • OK to take the first bullet.
- 9. 9 Single Responsibility Principle > Examples of SRP violation Computational Geometry Application Graphical Application GUI Rectangle draw() area() > This violation is bad for that: • We must include the GUI in the Computational Geometry application. • If a change to the Graphical Application causes the Rectangle to change, that change may force us to rebuild, retest, and redeploy the Computational Geometry Application.
- 10. 10 Single Responsibility Principle > A Class should have 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
- 11. 11 Single Responsibility Principle > Conform to SRP: Computational Geometry Application Graphical Application Rectangle draw() GUI Geometric Rectangle area()
- 13. 13 Interface Segregation Principle > Many client specific interfaces are better than one general purpose interface > Create an interface per client type not per client • Avoid needless coupling to clients GraphicalRect_I draw() Computational Geometry Application Graphical Application Rectangle draw() area() GUI GeometricRect_I Area()
- 14. 14 Liskov Substitution Principle “What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.” (Barbara Liskov, 1988)
- 15. 15 Liskov Substitution Principle > Any subclass should always be usable instead of its parent class. • Pre-conditions can only get weaker • Post-conditions can only get stronger > Derived classes should require no more and promise no less.
- 16. 16 Liskov Substitution Principle public interface Bird{ public void fly(); } public class Parrot implements Bird { public void fly() { System.out.println(“OK, I can fly.”); } } public class Penguin implements Bird { public void fly() { throw new IllegalStateExeption(“Sorry, I can not fly…”); } } >Example of LSP violation: public class BirdCustomer { …………….. Bird bird = new Parrot(); bird.fly(); …………….. …………….. bird = new Penguin(); bird.fly(); // oops, the customer will be surprised! ……………. ……………. }
- 17. 17 Liskov Substitution Principle public class Rectangle { public void setWidth(double w) { this.width = w; } public void setHeight(double h) { this.height = h; } public double area() { return this.width * this.height; } } public class Square extends Rectangle { public void setWidth(double w) { super.setWidth(w); super.setHeight(w); } public void setHeight(double h) { super.setWidth(h); super.setHeight(h); } } >Example of LSP violation: public class RectangleCustomer { …………….. Rectangel rect = new Square(); rect.setWidth(4); rect.setHeight(5); assert rect.area()==20;// oops, the customer will be surprised! ……………. ……………. }
- 18. 18 Liskov Substitution Principle > IS-A (inheritance) relationship refers to the BEHAVIOR of the class. > BEHAVIOR = public members.
- 19. 19 Dependency Inversion Principle > Procedural layering: violation of DIP Policy layer Mechanism layer Utility layer > Bad for: • Transitive dependency • Transitive change impacts
- 20. 20 Dependency Inversion Principle > A base class in an inheritance hierarchy should not know any of its subclasses > Modules with detailed implementations are not depended upon, but depend themselves upon abstractions > OCP states the goal; DIP states the mechanism; > LSP is the insurance for DIP 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
- 21. 21 Dependency Inversion Principle > OO layering: Conforming to DIP Policy Policy Layer Policy Service Interface Mechanism Mechanism Layer Mechanism Service Interface Utility Utility Layer
- 22. 22 Dependency Inversion Principle > This principle implies: • Programming to interfaces, not implementations. • Both the naming and the physical location of interfaces should respect their customers, not their implementations. • Dependency Injection. Anyway, I need to depend on a concrete implementation object at runtime, how can I get it?
- 23. 23 Dependency Inversion Principle > Dependency Injection: • Don’t use new operator to instantiate a concrete class where you need, instead inject it from outside. > Dependency Injection options: • Constructor Injection with PicoContainer • Setter Injection with Spring • Interface Injection • Using a Service Locator For details, refer to http://www.martinfowler.com/articles/injection.html
- 24. 24 OO Principles Reviewed > Encapsulate what varies. > Favor composition over inheritance. > Program to interfaces, not implementations. > Strive for loosely coupled designs between objects that interact. > Classes should be open for extension but closed for modification. > Depend on abstraction. Do not depend on concrete classes. > Only talk to your friends. > Don’t call us, we’ll call you. > A class should have only one reason to change. Oh, what is this?
- 25. 25 Law of Demeter > Only talk to your friends, also known as “Law of Demeter”. > Only invoke methods that belong to: • The object itself. • Objects passes in as a parameter to the method. • Any object the method creates or instantiates. • Any components of the object. (objects directly referred to) > Violating when you write a_object.m1().m2(); > Keep our circle of friends small clear responsibility decrease complexity > Law of Demeter for Concerns (LoDC) is good for Aspect Oriented Software Development.
- 26. 26 Agenda > Introduction > OO Design Principles > Evil Stuff and Anti-Patterns
- 27. 27 Evil Stuff > Singletons / Global variables • Singletons are actually OO global variables. > Getters, Setters • Evil for exposing information/implementation which should be hidden. • Eliminate data movement. Data flow is procedure-oriented thinking. • Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. • Exceptions: computational query, get/set an interface • http://www.javaworld.com/javaworld/jw-09-2003/jw-0905- toolbox.html?page=1 • http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html > Helper Classes • Actually global procedures, hard to maintain. • http://blogs.msdn.com/nickmalik/archive/2005/09/06/461404.aspx • http://blogs.msdn.com/nickmalik/archive/2005/09/07/462054.aspx
- 28. 28 Anti-Patterns > Category • Design related: The Blob, Poltergeist, Swiss Army Knife, Dead End • Development related: Golden Hammer, Input Kludge • Architecture related: Reinvent the wheel, Vendor lock-in > The category: • http://www.antipatterns.com/briefing/index.htm • http://www.devx.com/Java/Article/29162 > Poltergeist: http://www.icmgworld.com/corp/news/Articles/RS/jan_0302.asp > Dead End: http://www.icmgworld.com/corp/news/Articles/RS/jan_0402.asp
- 29. Much enough principles! Tired of this session? Here are some cookies
- 30. 30 Cookie – Thread Safe Singleton public class Singleton { private static Singleton instance = null; private Singleton() { } public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } } public class Singleton { private volatile static Singleton instance = null; private Singleton() { } public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } } volatile can make the double-check singleton thread safe, but only since Java5.
- 31. 31 Cookie – The dilemma of Observer private class Model extends Observable { public void handleAttributeChange(int value) { this.setChanged(); this.notifyObservers(value); } } Observer observer = new Observer() { public void update(Observable o, Object arg) { System.out.println(arg); } }; model.addObserver(observer) new Thread() { public void run() { model.handleAttributeChange(1); } }.start(); new Thread() { public void run() { model.handleAttributeChange(2); } }.start(); Not thread safe, notifications to observers may be lost! Notification order not guaranteed, early notification, maybe late received by observers.
- 32. 32 Cookie – The dilemma of Observer private class Model extends Observable { public synchronized void handleAttributeChange(int value) { this.setChanged(); this.notifyObservers(value); } } model.addObserver(observer); final Object object = new Object(); Observer observer = new Observer() { public void update(Observable o, Object arg) { synchronized (object) { System.out.println(arg); } } }; model.addObserver(observer); new Thread() { public void run() { synchronized (object) { model.addObserver() } } }.start(); model.handleAttributeChange(1); Notifications will not be lost. But, still not thread safe, dead-lock is permitted!