Student : Tạ Bảo Thắng

What is the S.O.L.I.D ?

SRP : Single Responsibility Principle
OCP : Open Closed Principle
LSP : Liskov Substitution Principle
ISP : Interface Segregation Principle
DIP : Dependency Inversion Principle
SRP : Single Responsibility Principle

“
“A class should have one and only one reason to change,
meaning that a class should have only one job.”
SRP : Single Responsibility Principle

“
SRP is about strong cohesion and loose coupling
Cohesion
 Relation of responsibilities
 Focused on single task
Coupling
 Dependency on other modules
 Relationship between modules
Ideal: low coupling + strong cohesion (e.g. a HDD)
Example: of a violation of the SRP.

Student

- Name : String too many

responsibilities

+ getStudentInfoText() : String
+ getStudentInfoHTML() : String
+ getStudentInfoJson() : String
+ saveToDatabase() : void
+ saveToFile() : void
 Student Fomatter
only format
- Name : String display
information

+ getName() : String
+ setName(String): void
+ fomatStudentText(Student) : String
+ fomatStudentHTML(Student) : String
+ fomatStudentJson(Student) : String
only contains
student information

Store
Each class
should have
- db : Database only one job.

+ SaveToDatabase(Student): void

only store information .

OCP : Open Closed Principle

“
“Each class should be open for extensions (sub-classes),
but closed for modifications.”

 Open to extension :
New behavior can be added later

 Closed to modification
Changes to source or binary code are not required
OCP : Open Closed Principle (2)

“
 Change behavior without changing the code?!
o Yes, this is possible, e.g. by inheritance

o Rely on abstractions, not on implementations

o Do not limit the variety of implementations

 Example: Design use OCP.

Method CaculateArea is
only deloyed in sublasses
 LSP : Liskov Substitution Principle

“
“Derived classes must be substitutable for their base
class.”

Substitutability -child classes must not:

 Remove parent class behavior

 Violate parent class intent

LSP : Liskov Substitution Principle Explained

“
 Functions that use pointers or references to base classes
must be able to use objects of derived classes without
knowing it.

Normal OOP inheritance

 IS-A relationship
 E.g. Dog is a kind of Animal
Liskov Substitution inheritance
 IS-SUBSTITUTABLE-FOR
 E.g. Animal is substitutable for Dog
 Example: of a violation of the LSP.

Bird

Penguin is a kind of Bird

but can not fly. It remove +….. Bird b = new Penguin();
behavior “fly” of Bird – b.fly(); -> error
+ fly()
parent class
Extend

Duck Penguin
@overide @overide
+ fly(){ + fly(){
sout(“Duck can
throw new
fly”)}
NoFlyException (); }
ISP : Interface Segregation Principle
“
“Clients should not be forced to depend on methods they do
not use”

Segregate interfaces

○Prefer small, cohesive interfaces

○Divide "fat" interfaces into smaller ones

ISP : Interface Segregation Principle Explained
“
Having "fat" interfaces leads to:

 Classes having methods they do not need

 Increased coupling

 Reduced flexibility
 Reduced maintainability
Example: of a violation of the ISP.

<<interface>> Fish
IAnimal
+Eat(){….}
+ Eat(); + Swim(){….}
+ Swim(); +…..
+ Fly(); implement + Fly(){ throw new
Exeption(“Can’t fly”)}
+…..
+ Drink(); Classes having
+ Sleep(); methods they
do not need Bird

+Eat(){….}
+ Fly(){….}
+…..
+ Swim(){ throw new
Exeption(“Can’t swim”)}
 Example: Design use ISP.

alwe
intosegregate
small, cohesiveinterface
interfaces as IAnimal
follows:
into small interfaces as follows:

<<interface>> <<interface>> <<interface>>

IBird IAnimal IFish

+ Fly(); + Eat();
+ Swim();
+ Sleep();
+ Drink();

FlappyBird Dog FomosaFish

+ Fly(){….} + Eat(){….} + Swim(){….}

+ Sleep(){…} + Eat(){…}
+ Drink(){…} +…
DIP : Dependency Inversion Principle

“
 High level modules should not depend upon
low level modules. Both should depend upon
abstractions.

 Abstractions should not depend upon details.

Details should depend upon abstractions.
Example: of a violation of the DIP.
Thanks!
Any questions?