Soild principles
-
Upload
avidnyat-chiddarwar -
Category
Engineering
-
view
241 -
download
0
Transcript of Soild principles
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