SOLID DESIGN PRINCIPLES

Avidnyat ChiddarwarSenior Technical Lead

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

“● 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

Design Principles

Open Close Principle

Interface Segregation Principle

Single Responsibility Principle

Dependency Inversion Principle

Liskov’s Substitution Principle

1.Single Responsibility

PrincipleA class should have only one reason

to change.

Single Responsibility Principle

Single Responsibility Principle

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.

Benefits Of Single Responsibility Principle

🔸Easier to test, read and maintain.🔸Less side effects.🔸Separation of concerns.🔸Naming does’nt gets tricky.

Example

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

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.

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.

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.

2.Open Closed

PrincipleOpen for extension and closed for

modification

Open Close Principle Real Example

Open for extension and close for modification

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.

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.

Example

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

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.

3.Liskov’s Substituion

PrincipleDerived types must be completely substitutable for their base types.

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.

Example

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.

4.Interface

Segregation Principle

Clients should not be forced to depend upon interfaces that they don't use.

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.

Example

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

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.

5.Dependency

Inversion PrincipleHigh-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.

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.

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.

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?

Example

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.

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.

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

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.

Q & A ?

Thank You !!!!Enjoy following principles….

Follow me @avidnyat