Hithesh N
Associate software engineer
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Inter face Segregation Principle
...
Code becomes more Testably (remember TDD is
not only about testing, more important its about
Design)
Apply ’smart’
- don...
 How can we tell when our code is rotting?
Rigidity

 Design is to hard change
Fragility

 Design is easy to break
Immobility

 Design is hard to reuse
Viscosity

 Design makes hard to do the right thing
Definition
 “Every object should have a single
responsibility and that responsibility should
be entirely encapsulated by ...
Example
 Two resposibilities

interface Modem {
public void dial(String pno);
public void hangup();
public void send(char...
 Separate into two interfaces
interface DataChannel {
public void send(char c);
public char recv();
}

interface Connecti...
Argument Against SRP
 “To Many classes and too difficult to understand the
BIG PICTURE”
 There are no more moving parts ...
What are some of the benefits
 Reuse - If all your class follow the SRP,you are more likely to reuse
some of them
 Clari...
 A module should be open to Extensibility ,but closed for
modification
 My translation: Change a class' behavior using
i...
Example
// Open-Close Principle - Bad example
class GraphicEditor {
public void drawShape(Shape s) {
if (s.m_type==1)
dra...
Open Closed Principle – a Few Problems…
 Impossible to add a new Shape without modifying
GraphEditor
 Important to under...
Open Closed Principle - Improved
 // Open-Close Principle - Good example
class GraphicEditor {
public void drawShape(Shap...
Challenges with using OCP?
Challenges
 Expensive – Requires significant effort

 Experience – best judgment

 Research – ask the right question
Liskov Substitution Principle

 “Derived classes must be substitutable for their base
class”
 My translation: Subclasses...
Liskov Substitution Principle
class Square extends Rectangle
// Violation of Liskov's Substitution Principle
{
class Rect...
Liskov Substitution Principle
class LspTest
{
private static Rectangle getNewRectangle()
{
// it can be an object returned...
Interface Segregation Principle
 "Clients should not be forced to depend upon
interfaces that they do not use.“

 My tra...
Interface Segregation Principle
//bad example (polluted interface)
interface Worker {
void work();
void eat();
}

ManWork...
Interface Segregation Principle
 Solution
- split into two interfaces

interface Workable {
public void work();
}

interf...
Dependency Inversion Principle
 A. High level modules should not depend upon low level
modules. Both should depend upon a...
Dependency Inversion Principle
//DIP - bad example
public class EmployeeService {
private EmployeeFinder emFinder //concre...
Dependency Inversion Principle
//DIP - fixed
public class EmployeeService {
private IEmployeeFinder emFinder //depends on ...
Q&A

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOo
d
http://www.oodesign.com
http://www.slideshare.net/enbohm
Solid Principles
Solid Principles
Solid Principles
Solid Principles
Solid Principles
Solid Principles
Upcoming SlideShare
Loading in …5
×

Solid Principles

483 views

Published on

Published in: Technology
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
483
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Solid Principles

  1. 1. Hithesh N Associate software engineer
  2. 2. Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Inter face Segregation Principle Dependency Inversion Principle
  3. 3. Code becomes more Testably (remember TDD is not only about testing, more important its about Design) 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!
  4. 4.  How can we tell when our code is rotting?
  5. 5. Rigidity  Design is to hard change
  6. 6. Fragility  Design is easy to break
  7. 7. Immobility  Design is hard to reuse
  8. 8. Viscosity  Design makes hard to do the right thing
  9. 9. Definition  “Every object should have a single responsibility and that responsibility should be entirely encapsulated by the class”  “Class should have one responsibility - one reason to change”  My translation: A class should concentrate on doing one thing and one thing only
  10. 10. Example  Two resposibilities interface Modem { public void dial(String pno); public void hangup(); public void send(char c); public char recv(); }  Connection Management + Data Communication
  11. 11.  Separate into two interfaces interface DataChannel { public void send(char c); public char recv(); } interface Connection { public void dial(String phn); public char hangup(); }
  12. 12. Argument Against SRP  “To Many classes and too difficult to understand the BIG PICTURE”  There are no more moving parts in a system with many small pieces than that with a few large pieces. The benefits outweigh this argument. Consistency, Good names and documentation make this a mute point.
  13. 13. What are some of the benefits  Reuse - If all your class follow the SRP,you are more likely to reuse some of them  Clarity - Your code is cleaner as your class don’t do unexpected things  Naming –As all your classes have a single responsibility, choosing a good name easy  Readability –Due to the clarity, better names and shorter files the readability is improved greatly  Smaller Function -
  14. 14.  A module should be open to Extensibility ,but closed for modification  My translation: Change a class' behavior using inheritance and composition
  15. 15. Example // 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; } }
  16. 16. Open Closed Principle – a Few Problems…  Impossible to add a new Shape without modifying GraphEditor  Important to understand GraphEditor to add a new Shape  Tight coupling between GraphEditor and Shape  Difficult to test a specific Shape without involving GraphEditor  If-Else-/Case should be avoided
  17. 17. Open Closed Principle - Improved  // 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 } }
  18. 18. Challenges with using OCP?
  19. 19. Challenges  Expensive – Requires significant effort  Experience – best judgment  Research – ask the right question
  20. 20. Liskov Substitution Principle  “Derived classes must be substitutable for their base class”  My translation: Subclasses should behave nicely when used in place of their base class
  21. 21. Liskov Substitution Principle class Square extends Rectangle // Violation of Liskov's Substitution Principle { class Rectangle public void setWidth(int width){ { m_width = width; int m_width; m_height = 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; } } public void setHeight(int height){ m_width = height; m_height = height; } }
  22. 22. Liskov Substitution Principle 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); // 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. } }
  23. 23. Interface Segregation Principle  "Clients should not be forced to depend upon interfaces that they do not use.“  My translation: Keep interfaces small
  24. 24. Interface Segregation Principle //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};
  25. 25. Interface Segregation Principle  Solution - split into two interfaces interface Workable { public void work(); } interface Feedable{ public void eat(); }
  26. 26. Dependency Inversion Principle  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.“  My translation: Use lots of interfaces and abstractions
  27. 27. Dependency Inversion Principle //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(…) } }
  28. 28. Dependency Inversion Principle //DIP - fixed public class EmployeeService { private IEmployeeFinder emFinder //depends on an abstraction, no animplementation public Employee findEmployee(…) { emFinder.findEmployee(…) } } Now its possible to change the finder to be a XmlEmployeeFinder, DBEmployeeFinder, FlatFileEmployeeFinder, MockEmployeeFinder….
  29. 29. Q&A http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOo d http://www.oodesign.com http://www.slideshare.net/enbohm

×