Object-oriented design principles

976 views

Published on

Summary of good object-oriented design principles which should be followed.

Published in: Engineering, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
976
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Object-oriented design principles

  1. 1. Object Oriented Design Principles –– class level Xiao-Yan Chen Beijing/July 13, 2007
  2. 2. 2 Agenda > Introduction > OO Design Principles > Evil Stuff and Anti-Patterns
  3. 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. 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. 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. 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. 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. 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. 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. 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. 11 Single Responsibility Principle > Conform to SRP: Computational Geometry Application Graphical Application Rectangle draw() GUI Geometric Rectangle area()
  12. 12. 12 Interface Segregation Principle
  13. 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. 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. 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. 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. 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. 18 Liskov Substitution Principle > IS-A (inheritance) relationship refers to the BEHAVIOR of the class. > BEHAVIOR = public members.
  19. 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. 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. 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. 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. 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. 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. 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. 26 Agenda > Introduction > OO Design Principles > Evil Stuff and Anti-Patterns
  27. 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. 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. 29. Much enough principles! Tired of this session? Here are some cookies 
  30. 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. 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. 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!
  33. 33. The End Thank You!

×