solid principles
TRANSCRIPT
SOLID Principles
Object Oriented Programming Principles
SOLID Overview
SOLID Principles:
S SRP Single Responsibility Principle
O OCP Open/Close Principle
L LSP Liskov Substitution Principle
I ISP Interface Segregation Principle
D DIP Dependency Inversion Principle
The Single Responsibility Principle
A class should have only one responsibility
The Single Responsibility Principle
An actor for a responsibility is the single source of
change for that responsibility. (Robert C. Martin)
The Single Responsibility Principle
Is this class reasonable?
What if we need to print the document to
multi formats as PDF, Printer?
The Single Responsibility Principle
No “Print” method in the class
Document is just an Entity
There are multi classes to do
the printing work.
Each class is a kind of Printer
The Single Responsibility Principle
The Single Responsibility Principle
Each class has only one role, one responsibility
In this example
Document defines the details of document, no more
responsibility
Printer defines how to print the document
If a change of printer is required, the related printer
should be changed, document and other printers not
required to change
An actor for a responsibility is the single source of
change for that responsibility. (Robert C. Martin)
The Open/Close Principle
Software entities should be open for extension, but closed for modification.
The Open/Close Principle
Software entities (classes, modules, functions, etc.)
should be open for extension, but closed for
modification
The Open/Close Principle
Let’s see this code
What if we need a new Shape?
The Open/Close Principle
If we need a new Shape:Create a new Shape “Trapezium” with new type id
Add a new method “drawTrapezium” to the class
GraphicEditor
Modify method drawShape to support new shape
We need to modify too much to have new Shape
The Open/Close Principle
Let’s see this code
No change on GraphicEditor
when a new Shape is added
To have a new Shape:
- just extend the Shape class
- override the draw method
The Open/Close Principle
Open for extension: Rectangle, Circle, Trapezium… extend from Shape
Closed to modification: GraphicEditor no need to change when new Shape
added
The Open/Close Principle
Software entities (classes, modules, functions, etc.)
should be open for extension, but closed for
modification
The Liskov Substitution Principle
Child classes should never break the parent class type definitions.
The Liskov Substitution Principle
Subtypes must be substitutable for their base types.
( Robert C. Martin)
The Liskov Substitution Principle
Square is a special Rectangle
with adjacent sides equal
The Liskov Substitution Principle
Let’s see this code
Square is a Rectangle
The Liskov Substitution Principle
Let’s see this code
- verifyArea always throws exception
with Square
- Square is not really a Rectangle
The Liskov Substitution Principle
Square is extended from Rectangle
But Square changes the characteristic of
Rectangle
So Square should not be a Rectangle
Square should not extended from Rectangle
The Liskov Substitution Principle
Subtypes must be substitutable for their base types.
( Robert C. Martin)
Because Square changes the characteristic of
Rectangle, so Square should not extend from
Rectangle
The Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they don't use.
The Interface Segregation Principle
The interface-segregation principle (ISP) states that
no client should be forced to depend on methods it
does not use.
The Interface Segregation Principle
The Interface Segregation Principle Let’s see this code
Workers needs to work
and eat also
But the Manager just
needs to take care how
they work
The Interface Segregation Principle
Worker still works and eats Robot just works, no need to
eat
By this way, Manager doesn’t need to know about the eat method that he doesn’t care
The Interface Segregation Principle
The interface-segregation principle (ISP) states that
no client should be forced to depend on methods it
does not use.
Because Manage doesn’t need to know abt how the
worker eats. The best way is IWorker doesn’t contain
eat method
The Dependency Inversion Principle
Depend upon Abstractions. Do not depend upon concretions.
The Dependency Inversion Principle
A. High-level modules should not depend on low-
level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details.
Details should depend upon abstractions.
The Dependency Inversion Principle Let’s see this code
AppManager depends on
EventLogWriter
If we need another way to
notify as Send SMS, Send
Mail, we need to change
AppManager
The Dependency Inversion Principle Update the code
The Dependency Inversion Principle
Every classes depend on INotificationActions
AppManager doesn’t depend on
Lower-level modules as
EventLogWriter, EmailSender,
SMSSender
INotificationAction
depends on Nothing
Reference
http://code.tutsplus.com/series/the-solid-principles--cms-634
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
http://www.oodesign.com/design-principles.html