The document outlines key software design principles to avoid poor design, including the single responsibility principle, open/closed principle, liskov's substitution principle, interface segregation principle, and dependency inversion principle. Each principle is explained along with its benefits and potential violations, emphasizing concepts like cohesion, coupling, and the need for decoupling high-level and low-level modules. The document also highlights important quality attributes of design principles such as understandability, changeability, extensibility, reusability, testability, and reliability.

1. SOLID DESIGN
PRINCIPLES
Avidnyat Chiddarwar
Senior Technical Lead

2. Design Principles!!!!
Software design principles represent a set of
guidelines that helps us to avoid having a
bad design.

3. “
● 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.
Characteristics of bad design

4. Design Principles
Open Close Principle
Interface Segregation Principle
Single Responsibility Principle
Dependency Inversion Principle
Liskov’s Substitution Principle

5. 1.
Single Responsibility Principle
A class should have only one reason
to change.

6. Single Responsibility Principle

7. Single Responsibility Principle

8. Single Responsibility Principle
There should be only one reason to change class.
If reasons are two then split the class.
To keep class more atomized as possible.
The concept could be extended to the methods of
class too, keeping easy the management of all
internal structure.

9. Benefits Of Single Responsibility Principle
Easier to test, read and maintain.
Less side effects.
Separation of concerns.
Naming does’nt gets tricky.

10. Example

12. Violation of SRP
3 reasons to change one class.
If one of the method breaks all modules depending on it will break.
Reading and maintaining becomes difficult.
Reusability is less.
Low cohesion, tightly coupled
If there is any new change to the class, developer has to
understand complete class all methods of that class and then can
start working on it. As well as tester has to test all methods again
instead of testing only added change.
Best example to give is fixing one bug raises 10 or more bugs

16. Benefits of SRP
Only 1 reason to change one class.
Reading and maintaining becomes easy.
Reusability is more.
High cohesion, loosely coupled
If there is any new change to the class, developer has to
understand only one class and methods of that class and then can
start working on it. As well as tester has to test few methods.

17. Attribute Of SRP - Cohesion
High cohesion.
Cohesion refers to the degree with which elements of code belong
together.
This means that the level of cohesion between elements is higher if
they are related, and lower if they are not.
Having a class with many methods that do one job means that
class has high cohesion.

18. Attribute Of SRP - Coupling
Low coupling.
Coupling is the manner of independence between modules of a
programming system.
This means that high coupling means that modules are more
dependent upon one another, and low coupling means they are
less dependent.
Having a class with many methods that do one job means that
that class has high cohesion.

19. 2.
Open Closed Principle
Open for extension and closed for modification

20. Open Close Principle Real Example
Open for extension and close for modification

21. Open Close Principle
An adapter in the wall is always closed for
modification, in other words we cannot change it
once it is fitted or extended if we want more.
But an adapter always provides a method of
extension, so we can plug in an extension board of
an adapter for more adaptation.
So you plug in an extension board and extend an
existing electric adapter fitted in wall.

22. Open Close Principle
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 will prefer
to extend it without changing the code that was
already written.

23. Example

25. Violation of Open Close Principle
Open for modification and closed for extension
If one of the method breaks all modules depending on it will break.
Reading and maintaining becomes difficult.
Reusability is less.
If there is any new change to the class, developer has to
understand complete class all methods of that class and then can
start working on it. As well as tester has to test all methods again
instead of testing only added change.
Best example to give is fixing one bug raises 10 or more bugs

27. Pros of Open Close Principle
Open for extension and closed for modification
If one of the method breaks other modules still remain intact.
Reusability is high.
If there is any new change to the class, developer does not have to
understand complete class all methods of that class and then can
start working on it.
As well as tester does not have to test all methods again instead of
that has to test only one change.
Applying strategy design pattern or template design pattern helps
in solving problem.

28. 3.
Liskov’s Substituion
Principle
Derived types must be completely substitutable
for their base types.

30. Liskov’s Substitution Principle
This principle is just an extension of the Open
Close 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.

31. Example

35. Cons of Liskov’s Substitution Principle
Difficult to understand why it broked after
substitution.
Developer has to understand and remember all
derived types and extra operations that class
does.
Difficult to change client code after substitution.

37. 4.
Interface Segregation
Principle
Clients should not be forced to depend upon
interfaces that they don't use.

41. Interface Segregation Principle
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.
As a conclusion Interfaces containing methods
that are not specific to it are called polluted or fat
interfaces. We should avoid them.

42. Example

45. Violations of Interface Segregation Principle
If robot class does not need eat method still it is
forced to implement.
As interface is polluted for any new change
developer has to understand complete class.
Reusability with huge cost

48. Pros of Interface Segregation Principle
Easy to read and understand.
Loosely coupled.
Reusability with low cost.
Developer has to understand only one interface
with small unit of code.

49. 5.
Dependency Inversion
Principle
High-level modules should not depend on low-
level modules. Both should depend on
abstractions.
Abstractions should not depend on details.
Details should depend on abstractions.

51. Dependency Inversion Principle
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.

52. Dependency Inversion Principle
In the classical way when a software
module(class, framework) need some other
module, it initializes and holds a direct reference
to it. This will make the 2 modules tight coupled.
In order 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.

53. Dependency Inversion Principle
When we design software applications we can consider the low
level classes the classes which implement basic and primary
operations(disk access, network protocols,...) and high level
classes the classes which encapsulate complex logic(business
flows, ...).
The last ones rely on the low level classes. A natural way of
implementing such structures would be to write low level classes
and once we have them to write the complex high level classes.
Since high level classes are defined in terms of others this seems
the logical way to do it. But this is not a flexible design. What
happens if we need to replace a low level class?

54. Example

56. Violations of Dependency Inversion Principle
We have to change the Manager class (remember
it is a complex one and this will involve time and
effort to make the changes).
Some of the current functionality from the
manager class might be affected.
The unit testing should be redone.
All those problems could take a lot of time to be
solved and they might induce new errors in the
old functionality.

58. Benefits of Dependency Inversion Principle
Manager class doesn't require changes when
adding SuperWorkers.
Minimized risk to affect old functionality present
in Manager class since we don't change it.
No need to redo the unit testing for Manager
class.

59. Quality Attributes of Design principles
Understandability:- The ease with which the
design fragment can be comprehended.
Changeability:- The ease with which a design
fragment can be modified when an existing
functionality is changed.
Extensibility:- The ease with which a design
fragment can be enhanced or extended for
suporting new functionality

60. Quality Attributes of Design principles
Reusability:- The ease with which a design
fragment can be used in a problem context other
than the one for which the design fragment was
originally developed.
Testability:- The ease with which a design
fragment supports the detection of defects within
it via testing.
Reliability:- The extent to which the design
fragment supports the correct realization fo the
functionality and helps guard against the
introduction of runtime problems.

62. Q & A ?

63. Thank You !!!!
Enjoy following principles….
Follow me @avidnyat