SOLID Design Principles

Introduction to SOLID design principles.

I have given this talk several times since 2011.

Transcript

1. 18.01.2018 1 SOLID Design Principles Michael Pershyn
2. 18.01.2018 2 Agenda • What are SOLID design principles • Why SOLID principles are here • The principles – SRP – OCP – LSP – ISP – DIP • Q&A
3. 18.01.2018 3 SOLID Design Principles • SOLID is a set of principles that help to produce better software and also to become a better Object-Orinted programmer • First described by Robert „Uncle Bob“ Martin
4. 18.01.2018 4 Why SOLID Principles are here • Helps create better software – High cohesion – Low coupling – High reusability – Low rigidity – Low fragility – Unit-testing-ready
5. 18.01.2018 5 Why SOLID Principles are here Guidelines for structures that can survive shifting tides
6. 18.01.2018 6 SRP – Single Responsibility There should never be more than one reason for a class to change Responsibility is a reason to change
7. 18.01.2018 7 SRP – Single Responsibility • What do you think of this design?
8. 18.01.2018 8 SRP – Single Responsibility • What do you think of this design?
9. 18.01.2018 9 SRP – Single Responsibility
10. 18.01.2018 10 SRP – Single Responsibility Be careful! You can make the code more decomposed than needed or even ready for some eventuality, that may never come.
11. 18.01.2018 11 OCP – Open/Closed Principle Software entities should be open for extension, but closed for modifcation. Class is written once. New behaviour is added by adding the new code and never by modifying the old.
12. 18.01.2018 12 OCP – Open/Closed Principle • How do we do it? Abstractions! • Abstractions are good. • Referencing concrete classes – bad.
13. 18.01.2018 13 LSP – Liskov Substitution Principle Subtypes may be substitute well for their base types
14. 18.01.2018 14 LSP – Liskov Substitution Principle Son of a farmer (and every farmer) should be able to do all the farmer work to keep the farm running.
15. 18.01.2018 15 ISP – Interface Segregation Principle Classes that implement interfaces, should not be forced to implement methods they do not use. Use smal interfaces, not fat.
16. 18.01.2018 16 ISP – Interface Segregation Principle • Example: IStream with Methods Reset(), Read(...), Write(...) – What is wrong?
17. 18.01.2018 17 ISP – Interface Segregation Principle
18. 18.01.2018 18 DIP – Dependency Inversion Principle High level modules should not depend on a low level modules. Both should depend on abstraction Abstractions should not depend on details. Details should depend on abstractions
19. 18.01.2018 19 DIP – Dependency Inversion Principle What about inversion? We invert the dependency – instead of depending on a concrete implementation we should depend on the interface. Then using LSP, we can write the implementation of the interface. And also we can wire a perfect mock that we can use to test our class properly, independently and fast.
20. 18.01.2018 20 DIP – Dependency Inversion Principle What about this? Imagine you need to change something in 3rd Level Module...
21. 18.01.2018 21 DIP – Dependency Inversion Principle What about this? Imagine you need to change something in Low-level Module...
22. 18.01.2018 22 SOLID and Testing Designing your system with SOLID in mind makes modules easier to understand, easier to mock and more testable Be wise and think of SOLID when designing systems
23. 18.01.2018 23 Questions? Thank you!
24. 18.01.2018 24