SOLID Principles Part 1
•Download as PPTX, PDF•
1 like•299 views
SOLID Principles Part 1 covers S = Single Responsibly Principle and O = Open / Closed Principle
Recommended
More Related Content
Similar to SOLID Principles Part 1
Similar to SOLID Principles Part 1 (20)
Recently uploaded
Recently uploaded (20)
SOLID Principles Part 1
- 2. Few Terminologies Basic OOP Cohesion Coupling Code Smells Design Smells Technical Debt Maulik Soni
- 3. Cohesion Cohesion refers to what the class (or module) will do Try to achieve High Cohesion Maulik Soni
- 4. Coupling How related are two classes / modules and how dependent they are on each other Try to achieve Loose Coupling Maulik Soni
- 5. Code Smells Duplicate code Long method Large class Temporary field Switch statements Parallel inheritance hierarchies Maulik Soni
- 6. Design Smells Rigidity Software is difficult to change Fragility Program breaks in many places when a change mode in a single place Immobility Parts could be useful in other systems, but effort and risk to separate from original system is too great. Maulik Soni
- 7. Design Smells Viscosity Design-preserving methods are more difficult to use than the hacks Development environment is slow and inefficient Needless complexity Contains elements that aren’t currently useful Needless repetition System has lots of repeated code elements Opacity A module is difficult to understand Maulik Soni
- 8. Technical Debt The cost to fix rotting code Interest charges build over time The longer we take to remove the smells, the more it will cost Maulik Soni
- 9. End of Introduction So Now, Let’s begin… Maulik Soni
- 10. SOLID Principles - I SRP – Single Responsibility Principle O/CP – Open Closed Principle Maulik Soni
- 11. What are SOLID Principles ? Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion Maulik Soni First five principles named by Robert C Martin in early 2000.
- 12. Why SOLID ? When Applied together it creates a system Easy to Maintain Easy to Extend over time To remove the Code Smells Part of overall strategy of agile and adaptive programming Maulik Soni
- 13. Why Solid ? Another View Maulik Soni To Deliver Fast To manage changes easily To deal with complexity
- 14. Single Responsibility Principle A software module should have one and only one responsibility Maulik Soni
- 16. Is SRP Violated Here ? Maulik Soni
- 17. Is SRP Violated Here ? Maulik Soni
- 18. Real world SRP Maulik Soni
- 19. SRP - Summary SRP is the simplest of the principles, and one of the hardest to get right We tend to join responsibilities together It's usually hard to see different responsibilities Maulik Soni
- 20. Open / Closed Principle All systems change during their life cycles avoid a cascade of changes to dependent modules When requirements change, you extend the behavior, not changing old code Maulik Soni
- 21. Open / Closed Principle Software Entities ( Classes, Modules, Functions Etc.) Should be open for extension but closed for modification Open for extension Behavior of the module can be extended We are able to change what the module does Closed for modification Extending behavior does not result in changes to source, binary, or code of the module Maulik Soni
- 22. Is O/CP Violated Here ? Maulik Soni
- 24. Open / Closed Rule of Thumb Use IF/SWITCH statements if number of cases are unlikely to change Use strategy pattern when number of cases are likely to change Don’t code for situations that you won’t ever need More smaller class files != more complicated code Maulik Soni
- 25. End of Presentation Maulik Soni
Editor's Notes
- Cohesion refers to what the class will do. Low cohesion would mean that the class does a great verity of actions and is not focused on what it should do. High cohesion would then mean that the class is focused on what it should be doing. I.e only method relating to the intention of the class.
- Tight Coupling – A class has a direct reference to a concrete class Loose Coupling – A class has a reference to an Abstraction which can be implemented by one or more classes. Benefits – Testability - Easier to test objects in isolation Reuse – dependencies can be swapped without modifying the target Applies Open / Closed Principle – change behavior without modifying the target
- SOLID is a mnemonic acronym introduced by Michael Feathers. Five basic principles of object-oriented programming and design.
- The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.[3] The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile andadaptive programming
- every class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its servicesshould be narrowly aligned with that responsibility.
- Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. As an example, consider a module that compiles and prints a report. Imagine such a module can be changed for two reasons. First, the content of the report could change. Second, the format of the report could change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.
- identify things that are changing for different reasons group together things that change for the same reason SRP requires very precise names, very focused classes
- identify things that are changing for different reasons group together things that change for the same reason SRP requires very precise names, very focused classes
- theorized in 1998 by Bertrand Meyer in a classical OO book
- Q : Is it possible to add new shape without changing the draw () method ? Yes. See it in next slide.
- Abstraction is the key! keep the things that change frequently away from things that don't change Rely on abstractions Interfaces Abstract classes Whenever I see switch statements, there is possible place to apply o/CP and some design patterns.
- This is the end of the presentation of SOLID principles. SRP and OCP. Hope next time when you come across code similar to this slide, you will at-least think is it violating any SOLID principles ?