Solid principles
0 likes•77 views
The document discusses the SOLID principles of object-oriented design, including the Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. For each principle, it provides an overview and example of how code may violate the principle as well as how to refactor the code to resolve the violation. The conclusion emphasizes that applying SOLID principles helps build systems that are easy to modify and extend over time, but following the principles alone does not guarantee good design.
Solid principles
- 1. SOLID PRINCIPLES with Ruby examples By Nhan Nguyen (nhanntit)
- 2. ROBERT C. MARTIN “Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.” Clean Code: A Handbook of Agile Software Craftsmanship
- 3. By following SOLID design principles, developers can achieve a maintainable and extendable codebase CONTENT
- 4. SINGLE RESPONSIBILITY PRINCIPLE A class should have a single responsibility. A class’s responsibility isn’t always immediately clear. Any complicated classes should be divided into smaller classes that are each responsible for a particular behaviour, making it easier to understand and maintain your codebase. The goal of the SR principle is to fight complexity that creeps in while you’re developing an application’s logic.
- 5. CHECK AN EXAMPLE Any violation SRP?
- 6. VIOLATIONS 1. Handling two tasks: generate_report!, send_report 2. May be problematic in expanding in the future: have to change the logic of the class
- 7. REFACTORED 1. Separate classes 2. Changing the logic of the class without touching the remaining class
- 8. OPEN-CLOSED PRINCIPLE Modules, classes, methods and other application entities should be open for extension but closed for modification. The codebase of software projects is often modified throughout their lifetimes. Therefore, a developer’s goal should be to build a flexible system that is easy to modify and extend. All modules, classes, methods, etc. should be designed in a modular way, so that we are able to change the behavior of the system without changing the source code.
- 9. CHECK AN EXAMPLE Any violation OCP?
- 10. VIOLATIONS 1. We’ll have to modify the logger every time we need to add additional senders or formatters
- 11. REFACTORED 1. Segregated senders and formatters to separate classes 2. Enabled the addition of new senders and formatters without having to modify the base code
- 12. LISKOV SUBSTITUTION PRINCIPLE Subclasses should add to a base class’s behaviour, not replace it. The principle states that parent instances should be replaceable with one of their child instances without creating any unexpected or incorrect behavior. LSP ensures that abstractions are correct, and helps developers achieve more reusable code and better organize class hierarchies
- 13. CHECK AN EXAMPLE Any violation LSP?
- 14. VIOLATIONS 1. The child class violates the LSP principle since it completely redefines the base class by returning a string with filtered data, whereas the base class returns an array of posts.
- 15. REFACTORED 1. Segregated the filtration logic and the statistics string generation logic into two methods: “posts“ and “formatted_posts“
- 16. THE INTERFACE SEGREGATION PRINCIPLE Clients shouldn’t depend on methods they don’t use. Several client-specific interfaces are better than one generalized interface. Main classes should be segregated into smaller specific classes, so their clients use only methods they need. We get the interfaces segregated according to their purpose, so we avoid “fat” classes and code that’s hard to maintain.
- 17. CHECK AN EXAMPLE Any violation ISP?
- 18. VIOLATIONS 1. Existing the unused methods for an instance
- 19. REFACTORED 1. Segregated in two interfaces with methods that perform specific tasks
- 20. THE DEPENDENCY INVERSION PRINCIPLE High-level modules shouldn’t depend on low-level modules. Abstractions shouldn’t depend on details. Details depend on abstractions The code that follows the LSP and OCP principles should be readable and contain clearly separated abstractions. It should also be extendable, and child classes should be easily replaceable by other instances of a base class without breaking the system.
- 21. CHECK AN EXAMPLE Any violation DIP?
- 22. VIOLATIONS 1. The classes PdfFormatter and HtmlFormatter may contain the logic that refers to other classes. Thus, we may impact all the related classes when modifying the class Printer
- 23. REFACTORED 1. High-level object (Printer) doesn’t depend directly on the implementation of low-level objects 2. Our high-level functionality is separated from all low-level details, so we’re able to easily change the low-level logic without system-wide implications
- 24. CONCLUSION Applied correctly, SOLID design recommendations can help you build system architecture that is easy to modify and extend over time Saying “Now my code conforms to SOLID design principles” is the wrong approach. Remember that SOLID principles themselves don’t guarantee great object-oriented design. Apply SOLID principles smartly
- 25. RELAX