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