An ultimate guide to SOLID Principles, developers must know.

Copyright © 2019 ONE BCG. All rights reserved.
SOLID Principles

2
• Separation of Concerns
• Extendibility
• Code Usability
• Maintainability
• Testability
Challenges in Applications

3
• Don’t repeat yourself - DRY
• Separation of Concerns
• Don’t make me Think
• Make it Simple
…….. Now question is how to do it...
How to Achieve It?

4
• Architectural Design Representation
• Architectural Design Output
• Architectural Styles
• Data-flow Architecture
• Object-oriented Architecture
• Layered Architecture
• Data-centered Architecture
• Call and Return Architecture
Follow Architectural Design Principles

5
Software design principles represent a set of guidelines that helps us to avoid having a
bad design. The design principles are associated with Robert Martin, who gathered them in
"Agile Software Development: Principles, Patterns, and Practices". According to Robert
Martin there are 3 important characteristics of a bad design that should be avoided:
● Rigidity - It is hard to change because every change affects too many other parts of
the system.
● Fragility - When you make a change, unexpected parts of the system break.
● Immobility - It is hard to reuse in another application because it cannot be
disentangled from the current application.
Design Principles

6
• S - Single Responsibility Principle - SRP
• O - Open/closed principle
• L - Liskov Substitution Principle - LSP
• I - Interface Segregation Principle
• D - Dependency Inversion Principle
SOLID Principle

7
Single Responsibility Principle was introduced by Tom DeMarco in his book Structured
Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and
defined the responsibility as a reason to change.
“A class should have only one reason to change”
What does it mean exactly… ??
The SRP is one of the simplest of the SOLID principles but also one of the most difficult to
get right. Collecting and gathering responsibilities to one place is a common thing to do
and happens in a natural way. Finding and separating those responsibilities from one
another is much of what software design is really about.
Single Responsibility Principle

8
This principle states that if we have 2 reasons to change for a class, we have to split the
functionality into two classes. Each class will handle only one responsibility and on the
future if we need to make one change we are going to make it in the class which handles
it. When we need to make a change in a class having more responsibilities the change
might affect the other functionality of the classes.
- A reason to change
A class or method should have only one reason to change.
- Single Responsibility
A class or method should have only a single responsibility.

9

10
Why Not?
When a class has more than one responsibility, there are also more triggers and reasons to
change that class. Responsibility is the same as “a reason for change” in this context.
Changes to one responsibility may impair or inhibit the class’s ability to meet the others.
This kind of coupling leads to fragile designs that break in unexpected ways when
changed. If a class has more than one responsibility, then the responsibilities become
coupled. Also when a (functional) responsibility is divided over more than one class, all
classes part of that responsibility have to change. They are caught in the chain of change.
Always try to give every class its own and unique responsibility.

11
How?
Separating responsibility can be done by defining for every responsibility a class or an
interface. It makes no difference, a class can be seen as nothing more than a container of
code, like a file or a library. What's important is that responsibilities are separated by
abstraction and therefore can be implemented by different consumers of that interface.

12
“Software entities like classes, modules, and functions should be open for extension
but closed for modifications.”
OPC is a generic principle. You can consider it when writing your classes to make sure that
when you need to extend their behavior you don’t have to change the class but to extend
it. The same principle can be applied for modules, packages, libraries. If you have a library
containing a set of classes there are many reasons for which you’ll prefer to extend it
without changing the code that was already written (backward compatibility, regression
testing, etc). This is why we have to make sure our modules follow the Open-Closed
Principle.
When referring to the classes Open Close Principle can be ensured by the use of Abstract
Classes and concrete classes for implementing their behavior. This will enforce having
Concrete Classes extending Abstract Classes instead of changing them. Some particular
cases of this are the Template Pattern and Strategy Pattern.
Open Closed Principle

13
How?
The best way to implement the open-closed principle is to first start with implementing the
Single Responsibility Principle: a class should have one, and only one, the reason to
change. This will separate different concerns in your code.
The next step is to represent these separate concerns by abstractions and let consumers
of these concerns talk to these abstractions.
To state the open-closed principle in a very straightforward way, you can say:

14
• You should design modules that never change.
• When requirements change, you extend the behavior of such modules by adding new
code, not by changing old code that already works.
• Abstraction is the way to realize this principle.
• Derivatives from abstraction are closed for modification because the abstraction is
fixed but behavior can be extended by creating new derivatives of the abstraction.

15
Liskov Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on
Object-Oriented Programming Systems Languages and Applications.
Barbara Liskov: “If S is a subtype of T, then objects of type T may be replaced with
objects of type S, without breaking the program.”
In other words...
“Derived types must be completely substitutable for their base types.”
This principle is just an extension of the Open-Closed Principle in terms of behavior
meaning that we must make sure that new derived classes are extending the base classes
without changing their behavior. The new derived classes should be able to replace the
base classes without any change in the code.
Still Confused….
Liskov Substitution Principle

16
The Liskov substitution principle (LSP) is a collection of guidelines for creating inheritance
hierarchies in which a client can reliably use any class or subclass without compromising
the expected behavior. If the rules of the LSP are not followed, an extension to a class
hierarchy—that is, a new subclass—might necessitate changes to any client of the base
class or interface.
If the LSP is followed, clients can remain unaware of changes to the class hierarchy. As
long as there are no changes to the interface, there should be no reason to change any
existing code. The LSP, therefore, helps to enforce both the open/closed principle and the
single responsibility principle.
Liskov Substitution Principle

17
“Clients should not be forced to depend upon
interfaces that they don't use.”
This principle teaches us to take care how we write our
interfaces. When we write our interfaces we should take
care to add only methods that should be there. If we add
methods that should not be there the classes
implementing the interface will have to implement those
methods as well. For example if we create an interface
called Worker and add a method lunch break, all the
workers will have to implement it. What if the worker is a
robot?
Interface Segregation Principle

18
1. “High-level modules should not depend on low-level modules. Both should
depend on abstractions.”
2. “Abstractions should not depend on details. Details should depend on
abstractions.”
Dependency Inversion Principle states that we should decouple high-level modules from
low-level modules, introducing an abstraction layer between the high-level classes and
low-level classes. Furthermore, it inverts the dependency: instead of writing our
abstractions based on details, we should write the details based on abstractions.
Dependency Inversion Principle

19
Dependency Inversion or Inversion of Control is better to know terms referring to how the
dependencies are realized. Classically when a software module(class, framework) needs
some other module, it initializes and holds a direct reference to it. This will make the 2
modules tight coupled. To decouple them the first module will provide a hook(a property,
parameter) and an external module controlling the dependencies will inject the reference
to the second one.
By applying the Dependency Inversion the modules can be easily changed by other
modules just changing the dependency module. Factories and Abstract Factories can be
used as dependency frameworks, but there are specialized frameworks for that, known as
Inversion of Control Container.
Dependency Inversion Principle

20

An ultimate guide to SOLID Principles, developers must know.

Recommended

Recommended

More Related Content

Similar to An ultimate guide to SOLID Principles, developers must know.

Similar to An ultimate guide to SOLID Principles, developers must know. (20)

More from ONE BCG

More from ONE BCG (11)

Recently uploaded

Recently uploaded (20)

An ultimate guide to SOLID Principles, developers must know.