Solid Principle
5 likes1,144 views
The document discusses object-oriented (OO) design principles. It defines design smells like rigidity, fragility, immobility, and viscosity that indicate poor design. It then explains principles for good OO design including the single responsibility principle (SRP), open/closed principle (OCP), Liskov substitution principle (LSP), interface segregation principle (ISP), and dependency inversion principle (DIP). SRP states a class should have one responsibility. OCP requires entities be open for extension but closed for modification. LSP defines inheritance and substitutability. ISP avoids fat interfaces. DIP inverts dependencies on abstractions, not concretions.
Solid Principle
- 1. The OO Design PrinciplesThe OO Design Principles
- 2. Agenda Need of Design Design Smells 2 Class Design Principles Summary
- 3. Agenda Need of Design Design Smells 3 Class Design Principles Summary
- 4. What's meaning of design..? What's the different compared to Design is about how What Design Exactly About is..? 4 compared to analysis..? Analysis is about what
- 5. Why do we Need Design..? To deliver faster To manage change Why do we need design..? 5 change To deal with complexity
- 6. Agenda Need of Design Design Smells 6 Class Design Principles Summary
- 7. Okay... I under stand the Importance of design How do we know a Design is bad..? Design Smells 7 Are they any symptoms Of bad design...
- 9. Rigidity Tendency for software to be difficult to change. The design is hard to change 9 Tendency for software to be difficult to change. Single change causes cascade of subsequent changes in dependent modules. The more module must be changed the more rigid the design.
- 10. Fragility Tendency of the software to break in many places every The design is easy to break 10 Tendency of the software to break in many places every time it's changed . The breakage occurs in areas with no conceptual relationship On every fix the software breaks in unexpected way.
- 11. Immobility Inability to reuse software from other projects or modules . Difficult to reuse 11 Inability to reuse software from other projects or modules . The useful module have to many dependencies. Cost of rewriting is less compared to the risk faced to separate those part.
- 12. Viscosity It's easy to do the wrong thing, but hard to do the right Hard to do the right thing 12 It's easy to do the wrong thing, but hard to do the right thing. When the design preserving methods are more difficult to use then the hacks When dev environment is slow and inefficient developer will be tempted to do wrong things.
- 13. Why design becomes rigid, Fragile Immobile and viscousIs there any Characteristics For good design Design Characteristics 13
- 14. High cohesion Improper dependencies Between modules Design Characteristics 14 Low coupling
- 15. So how can we Achieve good Design..? SRP LSP OCP Design Characteristics 15 ISP DIP So let's go SOLID..
- 16. Single Responsibility Principle There should never be more then one reason This is hard to see, as we think Responsibility in group 16 There should never be more then one reason to change a class. Many responsibility means many reason to change.
- 17. 1. Removes the immobility Smell from Design. 2. Deodorizes the Rigidity Smell Ohh.. SRP Benefits of SRP 17
- 18. Open Closed Principle Software entities should be open for extension, but closed for Abstraction is the key 18 Software entities should be open for extension, but closed for modification. Keep the things that change frequently away from things that don't change.
- 19. Open Closed Principle (contd…) Open for Extension Behavior of the module can be extended. Closed for Modification The source of such a module is invisible. OCP is the heart of object oriented design 19 Make the module behave in new and different ways as the requirement of the application change. Resist making source change to it.
- 20. Is 100% Closer possible Is there any techniques In Reality 100% Closer is not attainable. Closer must be Strategic. Abstraction is the key Further thinking of OCP 20 Flexibility, re usability and maintainability is The benefits
- 21. Liskov's SubstitutionPrinciple LSP defines the inheritance principle. Subclass should be substitutable for their base class 21 LSP defines the inheritance principle. It makes clear that in OO design IS-A relationship is about behavior; behavior that clients depend on. If client uses a base class, then it should not differentiate the base class.
- 22. LSP Violation Example void g(Rectangle r) { r.setWidth(5); r.setHeight(4); if(r.getArea() != 20) throw new Exception("Bad area!"); Square is not Rectangle! 22 Exception("Bad area!"); } IS-A Relationship Square’s behavior is changed, so it is not substitutable to Rectangle
- 23. Further thinking of LSP In order to be substitutable, the contract of the base class must be honored by the derived class. Derived class substitutable or base class, if Design by Contract 23 Derived class substitutable or base class, if Preconditions are no stronger then the base class Preconditions are no weaker then the base class Derived method should expect no more and provide no less
- 24. LSP Violation The solution will likely to be put into an if else statement in the client side. Are you sure it works? What happen if new derivatives of rectangle come..? May be we've allocate 24 May be we've allocate The responsibility Wrongly. It violates OCP
- 25. Interface Segregation Principle Client should not forced to depend on methods they do not Many client specific interface are Better then one general purpose interface 25 Client should not forced to depend on methods they do not use. ISP deals with designing cohesive interfaces and avoiding fat interfaces. What happen when the big class changes? All depending module must also change.
- 26. Service <<Client A methods>> + ... <<Client B methods>> + ... <<Client C methods>> + ... Client A Client B An violation of ISP example 26 ISP violation Client C
- 27. Segregated interface Service <<Interface>> Service A <<Client A methods>> + .. <<Interface>> Service B Client A An violation of ISP example: Solution 27 <<Client A methods>> + ... <<Client B methods>> + ... <<Client C methods>> + ... Service B <<Client B methods>> + .. <<Interface>> Service C <<Client C methods>> + .. Client B Client C
- 28. Dependency Inversion Principle High level module should not depend upon low level Depend upon abstraction. Do not depend Upon concretions 28 High level module should not depend upon low level modules, both should depends upon abstraction Abstraction should not depends upon on details, details should depends on abstraction.
- 30. DIP Summary Inversion of dependencies is the hallmark of good object oriented design. If it's dependencies are inverted, it has an OO design If it's dependencies are not inverted it has a procedural design. Dependency injection is the core of the famous spring 30 Dependency injection is the core of the famous spring framework Hollywood principle: “ Don't call us, we'll call you”.
- 31. Summary • A class should have only one reason to changeSRP • A Module should be open for extension but closed for modification.OCP • Subclass should be substitutable for their base LSP 31 • Subclass should be substitutable for their base class.LSP • Many client specific interfaces are better then one general purpose interface .ISP • Depends upon abstraction. Do not depends upon concretions.DIP