SOLID
Principles
ZUNERA ZAHID
2
Main Concept
SOLID is the most popular sets of design principles in object-
oriented software.
make software designs more understandable, flexible
and maintainable.
Generally, software should be written as simply as possible in
order to produce the desired result. However, once updating
the software becomes painful, the software’s design should
be adjusted to eliminate the pain.
3
Single Responsibility Principle
Open / Closed Principle
Concepts Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion
4
Single Responsibility Principle
Every Module, Class, or function should
have responsibility over a single part of
the functionality provided by
the software.
That responsibility should be
entirely encapsulated by the class.
5
Single
Responsibility
Principle
6
Single
Responsibility
Principle
7
Single
Responsibility
Principle
To solve that, let’s introduce the next principle:
8
Open –
closed
Principle
9
Open –
closed
Principle
10
Open – closed Principle
11
Open – closed Principle
Every Module, Class, or function should be
open for extension, but closed for
modification.
An entity can allow its behavior to be
extended without modifying its source
code.
12
Liskov Substitution principle
Objects in a program should be
replaceable with instances of their
subtypes without altering the correctness
of that program.
The Liskov substitution principle (LSP) is a
particular definition of a subtyping
relation, called (strong) behavioral
subtyping.
13
Liskov
Substitution
principle
14
Liskov
Substitution
principle
15
Interface Segregation Principle
No client should be forced to depend on
methods it does not use.
Many client-specific interfaces are better
than one general-purpose interface
Splits interfaces that are very large into
smaller and more specific ones so that
clients will only have to know about the
methods that are of interest to them.
16
Interface
Segregation
Principle
17
Interface
Segregation
Principle
18
Interface
Segregation
Principle
The way suggested by ISP is to create more client-specific
interfaces rather than one general-purpose interface. So, our
code example becomes:
19
Interface
Segregation
Principle
20
Interface Segregation
Principle
21
Dependency
inversion
principle
22
Dependency inversion principle
High-level modules should not depend on
low-level modules. Both should depend
on abstractions (e.g. interfaces).
Abstractions should not depend on
details. Details (concrete
implementations) should depend on
abstractions.
Software inevitably changes/evolves over time (maintenance, upgrade)
Single responsibility principle (SRP)
Every class should have only one reason to be changed
If class "A" has two responsibilities, create new classes "B" and "C" to
handle each responsibility in isolation, and then compose "A" out of "B"
and "C"
Open/closed principle (OCP)
Every class should be open for extension (derivative classes), but closed
for modification (fixed interfaces)
Put the system parts that are likely to change into implementations (i.e.
SOLID Design
concrete classes) and define interfaces around the parts that are unlikely
to change (e.g. abstract base classes)
Liskov substitution principle (LSP)
Principles Every implementation of an interface needs to fully comply with the
requirements of this interface (requirements determined by its clients!)
Any algorithm that works on the interface, should continue to work for any
substitute implementation
Interface segregation principle (ISP)
Keep interfaces as small as possible, to avoid unnecessary dependencies
Ideally, it should be possible to understand any part of the code in
isolation, without needing to look up the rest of the system code
Dependency inversion principle (DIP)
Instead of having concrete implementations communicate directly (and
depend on each other), decouple them by formalizing their
communication interface as an abstract interface based on the needs of
the higher-level class
23