solid principles
TRANSCRIPT
Design Smells
The symptoms are:
• Rigidity. The design is difficult to change.
• Fragility. The design is easy to break.
• Immobility. The design is difficult to reuse.
• Viscosity. It is difficult to do the right thing.
• Needless complexity. Overdesign.
• Needless repetition. Mouse abuse.
• Opacity. Disorganized expression.
Design Smells The Odors of Rotting Software
S O L I DHistory
Introduced by Robert C. Martins (”Uncle Bob”)
S O L I D
Five principles
SOLID
Single Responsibility Principle
Single Responsibility Principle
“There should never be more than one reason for a class to change”
Single Responsibility Principle
Just Because You Can, Doesn’t Mean You Should
Responsibility
• What a class does
• The more a class does, the more likely it will change
• The more a class changes, the more likely we will introduce bugs
Cohesion and Coupling
• Cohesion – How closely related are the different responsibilities of a module
• Coupling – How much one module relies on another
• Goal is low coupling and high cohesion
Single Responsibility Principle
Computational Geometric Application
GraphicalApplication+ Draw()
+ Area : double
GUI
Rectangle
This design violates SRP. The Rectangle class has two responsibilities. The first responsibility is toprovide a mathematical model of the geometry of a rectangle. The second responsibility is to renderthe rectangle on a GUI.
Rectangle
+ Draw()
Geometric Rectangle
+ Area() : double
GUI
GraphicalApplication
Computational Geometric Application
Single Responsibility Principle
Single Responsibility Principle
Sometimes hard to see…
Class is handling two responsibilities
1. Dial & Hang-up are related to connection Management
2. Send & Receive are related to DataCommunication
Single Responsibility Principle
More Classes != More Complex
Open Close Principle
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
• Open for extension
• Behavior of the module can be extended
• We are able to change what the module does
• Closed for modification
• Extending behavior does not result in changes to source, binary, or code of the module
Open Close Principle
Open Close Principle
Open Close Principle
Code Example
Open Close Principle
OCP Violation
• The GetDiscountPercentage() enforces some discount rules. Any change to the business rules in the future forces us to change the ShoppingCart class.
• This violates the Open / Closed Principle. A typical red flag is a switch statement, or if-else constructs with some business logic behind it.
• We need to design the ShoppingCart class in such a way that it is open to extension (like adding a new discount percentage) without modification. One way to establish this is by applying the Strategy Pattern.
Open Close Principle
Open Close Principle
Does not Violate OCP
Liskov Substitution Principle
Subtypes must be substitutable for their base typesTranslation: Subclasses should behave nicely when used in place of their base class
If It Looks Like A Duck, Quacks Like A Duck, But Needs Batteries - You Probably Have The Wrong Abstraction
Substitutability:
Child classes must not:
• 1. Remove base class behaviour
• 2. Violate base class invariants
And in General Must not require calling code to know they are different from their base type.
Liskov Substitution Principle
Liskov Substitution Principle
Code Example
Consider Refactoring to a new Base Class
• Given two classes that share a lot of behaviour but are not substitutable
• Create a third class that both can derive from
• Ensure substitutability is retained between each class and the new base
Liskov Substitution Principle
The Interface Segregation Principle
Clients should not be forced to depend on methods they do not use.
Tailor interfaces to individual client's needs
• If you implement an interface or derive from a base class and you have to throw an exception in a method because you don’t support it, the interface is probably too big.
ISP Smells
The Interface Segregation Principle
The Interface Segregation Principle
Now by changing the current interface you are doing an awful thing, disturbing the 1000 satisfied current client’s , even when they are not interested in the “Read” method. You are forcing them to use the “Read” method.
The Interface Segregation Principle
The Dependency-Inversion Principle
Would You Solder A Lamp Directly To The Electrical Wiring In A Wall?
The Dependency-Inversion Principle
• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend upon details. Details should depend upon abstractions.
• Two classes are tightly coupled if they are linked together and are dependent on each other
• Tightly coupled classes can not work independent of each other
• Makes changing one class difficult because it could launch a wave of changes through tightly coupled classes
The Dependency-Inversion Principle
Tight Coupling
Component A
Component B
Component C
The Dependency-Inversion Principle
The Dependency-Inversion Principle
Code Example
The Dependency-Inversion Principle
Component A
Component B
Component C
<<Interface>Component A
Service
<<Interface>Component B
Service
• Stubs, mocks, and fakes in unit tests are only possible when we have an interface to implement
The Dependency-Inversion Principle
Enables Testability
The Dependency-Inversion Principle
Composition Root
Application Entry Point
MVC Dependency Resolver
Programe.cs
WCF Service Host Factory
Asking for instantiating your dependencies only at the
Thank You