Do we need SOLID principles during software development?
2 likes•1,481 views
The document discusses the SOLID principles of object-oriented design. It defines each principle - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. It also addresses common project design issues SOLID principles can help solve like instability, immobility, and complexity. Both benefits and potential disadvantages of SOLID like an overuse of abstractions or small modules are presented.
Do we need SOLID principles during software development?
- 1. www.luxoft.com Do we need SOLID principles during software development? Luxoft Kiev 29.10.2015 Kseniya Shaposhnikova
- 2. www.luxoft.com Content What are SOLID principles? Single Responsibility Open Close Liskov Substitution Interface Segregation Dependency Inversion Project design issues SOLID principles pros and cons
- 3. www.luxoft.com What are SOLID principles? Object-oriented design principles that allow software engineers eliminate project issues by creating the best project based on existing properties.
- 4. www.luxoft.com Project design issues Instability Immobility Viscosity Tightness Uncertainty Unjustified Repetitions Unjustified Complexity
- 5. www.luxoft.com Single Responsibility Principle (SRP) There should be only one reason to change class
- 8. www.luxoft.com Open Close Principle (OCP) Software objects (classes, modules, functions, etc.) should be open to extension but close to modifications. Extension – addition of new behavior types (via abstractions) Modification – changes in binary modules
- 9. www.luxoft.com Strategy Pattern class Strategy «interface» EventHandler + processEvent(Event) : void Client - eventHandler: EventHandler DailyEventHandler + processEvent(Event) : void MonthlyEventHandler + processEvent(Event) : void
- 10. www.luxoft.com Template Method Pattern class Template Method ReportGenerator + generateReport() : void + retrieveData() : void + validateData() : void + createReport() : void Client - reportGenerator: ReportGenerator WeeklyReportGenerator + retrieveData() : void + validateData() : void + createReport() : void QuaterlyReportGenerator + retrieveData() : void + validateData() : void + createReport() : void Report generatorReport(){ Data data retrieveData(); boolean isValid=validateData(data); if (isValid){ return createReport(data); } ... }
- 11. www.luxoft.com Liskov Substitution Principle (LSP) Subtypes must be able to be replaced by base types.
- 13. www.luxoft.com Interface Segregation Principle (ISP) Clients should not become dependent on methods which they do not need.
- 14. www.luxoft.com Interface Segregation Principle Wrong class Interface Segregation «interface» ITextEditor + printContent() : void + saveContent() : void + copyText() : void + pasteText() : void DesktopEditor + printContent() : void + saveContent() : void + copyText() : void + pasteText() : void OnlineEditor + printContent() : void + saveContent() : void + copyText() : void + pasteText() : void CommandLineEditor + printContent() : void + saveContent() : void + copyText() : void + pasteText() : void
- 15. www.luxoft.com Interface Segregation Principle Right class Interface Segregation «interface» UITextEditor + copyText() : void + pasteText() : void «interface» BaseTextEditor + printContent() : void + saveContent() : void DesktopEditor + copyText() : void + printContent() : void + pasteText() : void + saveContent() : void OnlineEditor + copyText() : void + printContent() : void + pasteText() : void + saveContent() : void CommandLineEditor + printContent() : void + saveContent() : void
- 16. www.luxoft.com Dependency Inversion Principle (DIP) High-level modules should not depend from low-level modules. Both module types should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
- 17. www.luxoft.com Dependency Inversion Principle Wrong class Dependency Inversion BookingService + addBooking() : void ClientsStorage + getClient() : Client DiscountCalculator + calculateDiscount(Client) : double
- 18. www.luxoft.com Dependency Inversion Principle Right class Dependency Inversion BookingService + addBooking() : void «interface» IDiscountCalculator + getDiscount(Client) : int «interface» IClientsStorage + getClient() : Client ClientsCatalog + getClient() : Client BasicDiscountCalculator + getDiscount(Client) : int
- 19. www.luxoft.com Benefits of SOLID principles Changes in different parts of system do not affect unrelated parts. System is flexible for potential changes due to various abstractions. Each part of system can use only those set of exposed that it needs from interfaces. No need to implement unnecessary methods. Changes in details do not affect high-level abstractions.
- 20. www.luxoft.com Too many small code modules each having single responsibility. Hard to make changes in modules because it is difficult to predict which other parts use this small module. It’s hard to explore code dependencies because of large number of modules.
- 21. www.luxoft.com Too many abstractions. Create tests on early stages of development. Make development cycles short . Show results regularly to predict possible changes.
- 22. www.luxoft.com Too many interfaces. According to DIP we have to use references to interfaces instead of references to implementations. Do not invert dependencies for classes that remain unchanged.
- 23. www.luxoft.com We have to think over correct invariants on early stages. Class invariant is an invariant used to constrain objects of a class. The class invariant constrains the state stored in the object. Programming by contract can be used.
- 24. www.luxoft.com We segregate interfaces and have several ones instead of one. We have to hold all those references in class that consumes interfaces. Logically group interface methods but do not split them too much if it really is not needed in your concrete code. We have to hold references to several interfaces.
- 25. www.luxoft.com What did we talk about? Each SOLID principle described What issues SOLID principles allow to solve Pros and cons of each one
Editor's Notes
- #26: Отвечая на главный вопрос «Нужны ли СОЛИД принципы при разработке программного обеспечения» можно сказать, что они действительно нужны, поскольку они являются фундаментальными для объектно-ориентированного проектирования. Но пытаясь избежать чрезмерной сложности, неподвижности, неустойчивости, можно вернуться к тому, от чего пытались уйти, но уже в другом проявлении. Поэтому разработка - это постоянный поиск компромиссов - между эфективностью, прозводительность, гибкостью. И важно соблюдать необходимый баланс. То есть сделать приложение таким, чтобы оно не было переполнено ненужными уровнями абстракций, но в то же время было качественным и соответствовало требованиям.