Soild principles
Download as PPTX, PDF1 like465 views
The document outlines key software design principles to avoid poor design, including the single responsibility principle, open/closed principle, liskov's substitution principle, interface segregation principle, and dependency inversion principle. Each principle is explained along with its benefits and potential violations, emphasizing concepts like cohesion, coupling, and the need for decoupling high-level and low-level modules. The document also highlights important quality attributes of design principles such as understandability, changeability, extensibility, reusability, testability, and reliability.
Soild principles
- 1. SOLID DESIGN PRINCIPLES Avidnyat Chiddarwar Senior Technical Lead
- 2. Design Principles!!!! Software design principles represent a set of guidelines that helps us to avoid having a bad design.
- 3. “ ● Rigidity - It is hard to change because every change affects too many other parts of the system. ● Fragility - When you make a change, unexpected parts of the system break. ● Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application. Characteristics of bad design
- 4. Design Principles Open Close Principle Interface Segregation Principle Single Responsibility Principle Dependency Inversion Principle Liskov’s Substitution Principle
- 5. 1. Single Responsibility Principle A class should have only one reason to change.
- 8. Single Responsibility Principle There should be only one reason to change class. If reasons are two then split the class. To keep class more atomized as possible. The concept could be extended to the methods of class too, keeping easy the management of all internal structure.
- 9. Benefits Of Single Responsibility Principle Easier to test, read and maintain. Less side effects. Separation of concerns. Naming does’nt gets tricky.
- 10. Example
- 12. Violation of SRP 3 reasons to change one class. If one of the method breaks all modules depending on it will break. Reading and maintaining becomes difficult. Reusability is less. Low cohesion, tightly coupled If there is any new change to the class, developer has to understand complete class all methods of that class and then can start working on it. As well as tester has to test all methods again instead of testing only added change. Best example to give is fixing one bug raises 10 or more bugs
- 16. Benefits of SRP Only 1 reason to change one class. Reading and maintaining becomes easy. Reusability is more. High cohesion, loosely coupled If there is any new change to the class, developer has to understand only one class and methods of that class and then can start working on it. As well as tester has to test few methods.
- 17. Attribute Of SRP - Cohesion High cohesion. Cohesion refers to the degree with which elements of code belong together. This means that the level of cohesion between elements is higher if they are related, and lower if they are not. Having a class with many methods that do one job means that class has high cohesion.
- 18. Attribute Of SRP - Coupling Low coupling. Coupling is the manner of independence between modules of a programming system. This means that high coupling means that modules are more dependent upon one another, and low coupling means they are less dependent. Having a class with many methods that do one job means that that class has high cohesion.
- 19. 2. Open Closed Principle Open for extension and closed for modification
- 20. Open Close Principle Real Example Open for extension and close for modification
- 21. Open Close Principle An adapter in the wall is always closed for modification, in other words we cannot change it once it is fitted or extended if we want more. But an adapter always provides a method of extension, so we can plug in an extension board of an adapter for more adaptation. So you plug in an extension board and extend an existing electric adapter fitted in wall.
- 22. Open Close Principle OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don’t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you will prefer to extend it without changing the code that was already written.
- 23. Example
- 25. Violation of Open Close Principle Open for modification and closed for extension If one of the method breaks all modules depending on it will break. Reading and maintaining becomes difficult. Reusability is less. If there is any new change to the class, developer has to understand complete class all methods of that class and then can start working on it. As well as tester has to test all methods again instead of testing only added change. Best example to give is fixing one bug raises 10 or more bugs
- 27. Pros of Open Close Principle Open for extension and closed for modification If one of the method breaks other modules still remain intact. Reusability is high. If there is any new change to the class, developer does not have to understand complete class all methods of that class and then can start working on it. As well as tester does not have to test all methods again instead of that has to test only one change. Applying strategy design pattern or template design pattern helps in solving problem.
- 28. 3. Liskov’s Substituion Principle Derived types must be completely substitutable for their base types.
- 30. Liskov’s Substitution Principle This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.
- 31. Example
- 35. Cons of Liskov’s Substitution Principle Difficult to understand why it broked after substitution. Developer has to understand and remember all derived types and extra operations that class does. Difficult to change client code after substitution.
- 37. 4. Interface Segregation Principle Clients should not be forced to depend upon interfaces that they don't use.
- 41. Interface Segregation Principle This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.
- 42. Example
- 45. Violations of Interface Segregation Principle If robot class does not need eat method still it is forced to implement. As interface is polluted for any new change developer has to understand complete class. Reusability with huge cost
- 48. Pros of Interface Segregation Principle Easy to read and understand. Loosely coupled. Reusability with low cost. Developer has to understand only one interface with small unit of code.
- 49. 5. Dependency Inversion Principle High-level modules should not depend on low- level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
- 51. Dependency Inversion Principle Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes.
- 52. Dependency Inversion Principle In the classical way when a software module(class, framework) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter) and an external module controlling the dependencies will inject the reference to the second one.
- 53. Dependency Inversion Principle When we design software applications we can consider the low level classes the classes which implement basic and primary operations(disk access, network protocols,...) and high level classes the classes which encapsulate complex logic(business flows, ...). The last ones rely on the low level classes. A natural way of implementing such structures would be to write low level classes and once we have them to write the complex high level classes. Since high level classes are defined in terms of others this seems the logical way to do it. But this is not a flexible design. What happens if we need to replace a low level class?
- 54. Example
- 56. Violations of Dependency Inversion Principle We have to change the Manager class (remember it is a complex one and this will involve time and effort to make the changes). Some of the current functionality from the manager class might be affected. The unit testing should be redone. All those problems could take a lot of time to be solved and they might induce new errors in the old functionality.
- 58. Benefits of Dependency Inversion Principle Manager class doesn't require changes when adding SuperWorkers. Minimized risk to affect old functionality present in Manager class since we don't change it. No need to redo the unit testing for Manager class.
- 59. Quality Attributes of Design principles Understandability:- The ease with which the design fragment can be comprehended. Changeability:- The ease with which a design fragment can be modified when an existing functionality is changed. Extensibility:- The ease with which a design fragment can be enhanced or extended for suporting new functionality
- 60. Quality Attributes of Design principles Reusability:- The ease with which a design fragment can be used in a problem context other than the one for which the design fragment was originally developed. Testability:- The ease with which a design fragment supports the detection of defects within it via testing. Reliability:- The extent to which the design fragment supports the correct realization fo the functionality and helps guard against the introduction of runtime problems.
- 62. Q & A ?
- 63. Thank You !!!! Enjoy following principles…. Follow me @avidnyat