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.
SOLID -  OO DESIGN PRINCIPLES Andreas Enbohm, Capgemini
Agenda <ul><li>What is SOLID Design Principles? </li></ul><ul><li>Code Examples  </li></ul><ul><li>Q&A </li></ul>26 august...
SOLID <ul><li>Introduced by Robert C. Martins (”Uncle Bob”) </li></ul><ul><li>Agile Manifesto </li></ul><ul><li>Author of ...
SOLID <ul><li>SOLID -  S ingle Responsibility Principle -  O pen Closed Principle -  L iskov Substitution Principle -  I n...
Single  Responsibility  Principle <ul><li>&quot;There should never be more than one reason for a class to change.&quot; — ...
Single Responsibility Principle <ul><li>Two resposibilities </li></ul><ul><li>Connection Management + Data Communication <...
Single Responsibility Principle <ul><li>Separate into two interfaces </li></ul>26 augusti 2011 Sida  interface DataChannel...
Open Closed Principle <ul><li>&quot;Software entities (classes, modules, functions, etc.) should be open for extension, bu...
Open Closed Principle 26 augusti 2011 Sida  // Open-Close Principle - Bad example class GraphicEditor { public void drawSh...
Open Closed Principle – a Few Problems…. <ul><li>Impossible to add a new  Shape  without modifying  GraphEditor </li></ul>...
Open Closed Principle - Improved <ul><li>// Open-Close Principle - Good example class GraphicEditor { public void drawShap...
Liskov Substitution Principle <ul><li>&quot;Functions that use pointers or references to base classes must be able to use ...
Liskov Substitution Principle 26 augusti 2011 Sida  // Violation of Liskov's  Substitution   Principle class Rectangle { i...
Liskov Substitution Principle <ul><li>class LspTest { private static Rectangle getNewRectangle() { // it can be an object ...
Interface Segregation Principle <ul><li>&quot;Clients should not be forced to depend upon interfaces that they do not use....
Interface Segregation Principle <ul><li>Don’t force classes so implement methods they can’t (Swing/Java) </li></ul><ul><li...
Interface Segregation Principle 26 augusti 2011 Sida  //bad example (polluted interface) interface Worker { void work(); v...
Interface Segregation Principle <ul><li>Solution - split into two interfaces </li></ul>26 augusti 2011 Sida  interface Wor...
Dependency Inversion Principle <ul><li>&quot;A. High level modules should not depend upon low level modules. Both should d...
Dependency Inversion Principle 26 augusti 2011 Sida  //DIP - bad example public class EmployeeService { private EmployeeFi...
Dependency Inversion Principle <ul><li>Now its possible to change the finder to be a XmlEmployeeFinder, DBEmployeeFinder, ...
Q&A <ul><li>http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod </li></ul><ul><li>http://www.oodesign.com </li></ul><...
Upcoming SlideShare
Loading in …5
×

SOLID Design Principles

12,856 views

Published on

A presentation about SOLID design principles in OO software systems.

Published in: Technology
  • Hello, you were wrong in "Liskov Substitution Principle". It not only allow a base type to refer to a derived instance but also the derived class should not alter any of the desirable properties of that program. For example, Cat, Dog, Tiger could derived from Animal base class and they all have Run() method, but a Bike class should not derived from Animal although it also has Run() method. The reason is because Cat, Dog and Tiger can Run() anytime they want but the Bike needs to be kicked off before Run().
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

SOLID Design Principles

  1. 1. SOLID - OO DESIGN PRINCIPLES Andreas Enbohm, Capgemini
  2. 2. Agenda <ul><li>What is SOLID Design Principles? </li></ul><ul><li>Code Examples </li></ul><ul><li>Q&A </li></ul>26 augusti 2011 Sida
  3. 3. SOLID <ul><li>Introduced by Robert C. Martins (”Uncle Bob”) </li></ul><ul><li>Agile Manifesto </li></ul><ul><li>Author of several books, e.g. ”Clean Code” </li></ul>26 augusti 2011 Sida
  4. 4. SOLID <ul><li>SOLID - S ingle Responsibility Principle - O pen Closed Principle - L iskov Substitution Principle - I nterface Segregation Principle - D ependency Inverison Principle </li></ul><ul><li>Code becomes more Testably (remember TDD is not only about testing, more important its about Design) </li></ul><ul><li>Apply ’smart’ - don’t do stuff ’just because of’ - very importad to see the context of the program/code when applying SOLID - Joel On Software advise – use with common sense! </li></ul>26 augusti 2011 Sida
  5. 5. Single Responsibility Principle <ul><li>&quot;There should never be more than one reason for a class to change.&quot; — Robert Martin, SRP paper linked from The Principles of OOD </li></ul><ul><li>My translation: A class should concentrate on doing one thing and one thing only </li></ul>26 augusti 2011 Sida
  6. 6. Single Responsibility Principle <ul><li>Two resposibilities </li></ul><ul><li>Connection Management + Data Communication </li></ul>26 augusti 2011 Sida interface Modem { public void dial(String pno); public void hangup(); public void send(char c); public char recv(); }
  7. 7. Single Responsibility Principle <ul><li>Separate into two interfaces </li></ul>26 augusti 2011 Sida interface DataChannel { public void send(char c); public char recv(); } interface Connection { public void dial(String phn); public char hangup(); }
  8. 8. Open Closed Principle <ul><li>&quot;Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.&quot; — Robert Martin paraphrasing Bertrand Meyer, OCP paper linked from The Principles of OOD </li></ul><ul><li>My translation: Change a class' behavior using inheritance and composition </li></ul>26 augusti 2011 Sida
  9. 9. Open Closed Principle 26 augusti 2011 Sida // Open-Close Principle - Bad example class GraphicEditor { public void drawShape(Shape s) { if (s.m_type==1) drawRectangle(s); else if (s.m_type==2) drawCircle(s); } public void drawCircle(Circle r) {....} public void drawRectangle(Rectangle r) {....} } class Shape { int m_type; } class Rectangle extends Shape { Rectangle() { super.m_type=1; } } class Circle extends Shape { Circle() { super.m_type=2; } }
  10. 10. Open Closed Principle – a Few Problems…. <ul><li>Impossible to add a new Shape without modifying GraphEditor </li></ul><ul><li>Important to understand GraphEditor to add a new Shape </li></ul><ul><li>Tight coupling between GraphEditor and Shape </li></ul><ul><li>Difficult to test a specific Shape without involving GraphEditor </li></ul><ul><li>If-Else-/Case should be avoided </li></ul>26 augusti 2011 Sida
  11. 11. Open Closed Principle - Improved <ul><li>// Open-Close Principle - Good example class GraphicEditor { public void drawShape(Shape s) { s.draw(); } } class Shape { abstract void draw(); } class Rectangle extends Shape { public void draw() { // draw the rectangle } } </li></ul>26 augusti 2011 Sida
  12. 12. Liskov Substitution Principle <ul><li>&quot;Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.&quot; — Robert Martin, LSP paper linked from The Principles of OOD </li></ul><ul><li>My translation: Subclasses should behave nicely when used in place of their base class </li></ul>26 augusti 2011 Sida
  13. 13. Liskov Substitution Principle 26 augusti 2011 Sida // Violation of Liskov's Substitution Principle class Rectangle { int m_width; int m_height; public void setWidth(int width){ m_width = width; } public void setHeight(int h){ m_height = ht; } public int getWidth(){ return m_width; } public int getHeight(){ return m_height; } public int getArea(){ return m_width * m_height; } } class Square extends Rectangle { public void setWidth(int width){ m_width = width; m_height = width; } public void setHeight(int height){ m_width = height; m_height = height; } }
  14. 14. Liskov Substitution Principle <ul><li>class LspTest { private static Rectangle getNewRectangle() { // it can be an object returned by some factory ... return new Square(); } public static void main (String args[]) { Rectangle r = LspTest.getNewRectangle(); r.setWidth(5); r.setHeight(10); </li></ul><ul><li>// user knows that r it's a rectangle. It assumes that he's able to set the width and height as for the base class System.out.println(r.getArea()); // now he's surprised to see that the area is 100 instead of 50. } } </li></ul>26 augusti 2011 Sida
  15. 15. Interface Segregation Principle <ul><li>&quot;Clients should not be forced to depend upon interfaces that they do not use.&quot; — Robert Martin, ISP paper linked from The Principles of OOD </li></ul><ul><li>My translation: Keep interfaces small </li></ul>26 augusti 2011 Sida
  16. 16. Interface Segregation Principle <ul><li>Don’t force classes so implement methods they can’t (Swing/Java) </li></ul><ul><li>Don’t pollute interfaces with a lot of methods </li></ul><ul><li>Avoid ’fat’ interfaces </li></ul>26 augusti 2011 Sida
  17. 17. Interface Segregation Principle 26 augusti 2011 Sida //bad example (polluted interface) interface Worker { void work(); void eat(); } ManWorker implements Worker { void work() {…}; void eat() {30 min break;}; } RobotWorker implements Worker { void work() {…}; void eat() {//Not Appliciable for a RobotWorker}; }
  18. 18. Interface Segregation Principle <ul><li>Solution - split into two interfaces </li></ul>26 augusti 2011 Sida interface Workable { public void work(); } interface Feedable{ public void eat(); }
  19. 19. Dependency Inversion Principle <ul><li>&quot;A. High level modules should not depend upon low level modules. Both should depend upon abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions.&quot; — Robert Martin, DIP paper linked from The Principles of OOD </li></ul><ul><li>My translation: Use lots of interfaces and abstractions </li></ul>26 augusti 2011 Sida
  20. 20. Dependency Inversion Principle 26 augusti 2011 Sida //DIP - bad example public class EmployeeService { private EmployeeFinder emFinder //concrete class, not abstract. Can access a SQL DB for instance public Employee findEmployee(…) { emFinder.findEmployee(…) } }
  21. 21. Dependency Inversion Principle <ul><li>Now its possible to change the finder to be a XmlEmployeeFinder, DBEmployeeFinder, FlatFileEmployeeFinder, MockEmployeeFinder…. </li></ul>26 augusti 2011 Sida //DIP - fixed public class EmployeeService { private IEmployeeFinder emFinder //depends on an abstraction, no an implementation public Employee findEmployee(…) { emFinder.findEmployee(…) } }
  22. 22. Q&A <ul><li>http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod </li></ul><ul><li>http://www.oodesign.com </li></ul><ul><li>http://www.slideshare.net/enbohm </li></ul><ul><li>Twitter: enbohm </li></ul>26 augusti 2011 Sida

×