SOLID Design Principles

SOLID Design Principles

Introduction to SOLID design principles.

I have given this talk several times since 2011.


Michael Pershyn

June 02, 2011


  1. 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
  2. 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
  3. 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
  4. 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
  5. 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.
  6. 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.
  7. 12.

    18.01.2018 12 OCP – Open/Closed Principle • How do we

    do it? Abstractions! • Abstractions are good. • Referencing concrete classes – bad.
  8. 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.
  9. 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.
  10. 16.

    18.01.2018 16 ISP – Interface Segregation Principle • Example: IStream

    with Methods Reset(), Read(...), Write(...) – What is wrong?
  11. 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
  12. 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.
  13. 20.

    18.01.2018 20 DIP – Dependency Inversion Principle What about this?

    Imagine you need to change something in 3rd Level Module...
  14. 21.

    18.01.2018 21 DIP – Dependency Inversion Principle What about this?

    Imagine you need to change something in Low-level Module...
  15. 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