The document discusses the SOLID principles of object-oriented design: 1. The Single Responsibility Principle states that a class should have one, and only one, reason to change. 2. The Open/Closed Principle states that software entities should be open for extension but closed for modification. 3. The Liskov Substitution Principle states that child classes must be substitutable for their parent classes. 4. The Interface Segregation Principle states that clients shouldn't depend on interfaces they don't use. 5. The Dependency Inversion Principle states that high-level modules shouldn't depend on low-level modules, and both should depend on abstractions. Concrete

1. SOLID Principles
Object Oriented Programming Principles

2. 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

3. The Single Responsibility Principle
A class should have only one responsibility

4. The Single Responsibility Principle
An actor for a responsibility is the single source of
change for that responsibility. (Robert C. Martin)

5. The Single Responsibility Principle
Is this class reasonable?
What if we need to print the document to
multi formats as PDF, Printer?

6. 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

7. The Single Responsibility Principle

8. 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)

9. The Open/Close Principle
Software entities should be open for extension, but closed for
modification.

10. The Open/Close Principle
Software entities (classes, modules, functions, etc.)
should be open for extension, but closed for
modification

11. The Open/Close Principle
Let’s see this code
What if we need a new Shape?

12. 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

13. 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

14. The Open/Close Principle

15. 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

16. The Liskov Substitution Principle
Child classes should never break the parent class type definitions.

17. The Liskov Substitution Principle
Subtypes must be substitutable for their base types.
( Robert C. Martin)

18. The Liskov Substitution Principle
Square is a special Rectangle
with adjacent sides equal

19. The Liskov Substitution Principle
Let’s see this code
Square is a Rectangle

20. The Liskov Substitution Principle
Let’s see this code
- verifyArea always throws exception
with Square
- Square is not really a Rectangle

21. 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

22. 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

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

24. The Interface Segregation Principle
The interface-segregation principle (ISP) states that
no client should be forced to depend on methods it
does not use.

25. The Interface Segregation Principle

26. 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

27. 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

28. 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

29. The Dependency Inversion Principle
Depend upon Abstractions. Do not depend upon concretions.

30. 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.

31. 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

32. The Dependency Inversion Principle
Update the code

33. 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

34. 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