SlideShare a Scribd company logo
1 of 84
Download to read offline
Mental Log - Week 3
Object Oriented Design Principles
Class Design Principles
Dinh Hoang Long
Mental Log
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 1/33
Outline
Overview
Bad Design
Class Design Principles
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 2/33
Overview
Design Principles
“Software design principles represent a set of guidelines that
helps us to avoid having a bad design.”
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
Overview
Design Principles
“Software design principles represent a set of guidelines that
helps us to avoid having a bad design.”
Identified by Robert C. Martin (Uncle Bob) in the early 2000s.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
Overview
Design Principles
“Software design principles represent a set of guidelines that
helps us to avoid having a bad design.”
Identified by Robert C. Martin (Uncle Bob) in the early 2000s.
Gathered in ”Agile Software Development: Principles,
Patterns, and Practices” (2003).
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
Overview
Design Principles
“Software design principles represent a set of guidelines that
helps us to avoid having a bad design.”
Identified by Robert C. Martin (Uncle Bob) in the early 2000s.
Gathered in ”Agile Software Development: Principles,
Patterns, and Practices” (2003).
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
Overview
Design Principles
“Software design principles represent a set of guidelines that
helps us to avoid having a bad design.”
Identified by Robert C. Martin (Uncle Bob) in the early 2000s.
Gathered in ”Agile Software Development: Principles,
Patterns, and Practices” (2003).
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
Object Oriented Design Principles
Class Design Principles (5)
Package Cohesion Principles (3)
Package Coupling Principles (3)
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 4/33
Object Oriented Design Principles
Clas Design Principles
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 5/33
Object Oriented Design Principles
Package Cohesion Principles
Release Reuse Equivalency Principle
Common Closure Principle
Common Reuse Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 6/33
Object Oriented Design Principles
Package Coupling principles
Acyclic Dependencies Principle
Stable Dependencies Principle
Stable Abstractions Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 7/33
Bad Code
Rigidity - It is hard to change because every change affects
too many other parts of the system.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 8/33
Bad Code
Rigidity - It is hard to change because every change affects
too many other parts of the system.
Fragility - When you make a change, unexpected parts of the
system break.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 8/33
Bad Code
Rigidity - It is hard to change because every change affects
too many other parts of the system.
Fragility - When you make a change, unexpected parts of the
system break.
Immobility - It is hard to reuse in another application because
it cannot be disentangled from the current application.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 8/33
Class Design Principles
Single Responsibility Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
Class Design Principles
Single Responsibility Principle
Open-Closed Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
Class Design Principles
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
Class Design Principles
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
Class Design Principles
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
Class Design Principles
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Dependency Inversion Principle
Interface Segregation Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 10/33
Single Responsibility Principle
Figure 1: Real World
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 11/33
Single Responsibility Principle
Figure 1: Real World
Intent:
“A class should have only one reason to change.”
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 11/33
Single Responsibility Principle
Another Definition:
“Every software module should have only one reason to change”
Software Module - Class, Function,...
Reason to change - Responsibility
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 12/33
Single Responsibility Principle
Question
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
Single Responsibility Principle
Question
A class will have single responsibility.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
Single Responsibility Principle
Question
A class will have single responsibility.
A function will have single responsibility.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
Single Responsibility Principle
Question
A class will have single responsibility.
A function will have single responsibility.
A class will have more than one function.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
Single Responsibility Principle
Question
A class will have single responsibility.
A function will have single responsibility.
A class will have more than one function.
→ A class will have more than one responsibility?
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
Single Responsibility Principle
Figure 2: Factory Implementation
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 14/33
Single Responsibility Principle
Drawbacks?
The so called ’Class Explosion’. Our application may end
up with too many classes to manage.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 15/33
Single Responsibility Principle
Drawbacks?
The so called ’Class Explosion’. Our application may end
up with too many classes to manage.
There are a lot of class, so when I want to change
something, I can’t find the code I need to change.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 15/33
Single Responsibility Principle
The Single-Responsibility Principle is one of the simplest
principles but one of the most difficult to get right.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 16/33
Single Responsibility Principle
The Single-Responsibility Principle is one of the simplest
principles but one of the most difficult to get right.
Recommendation
“The first rule of functions is that they should be small. The
second rule of functions is that they should be smaller than
that.” (Clean Code, Chapter 3: Functions)
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 16/33
Single Responsibility Principle
The Single-Responsibility Principle is one of the simplest
principles but one of the most difficult to get right.
Recommendation
“The first rule of functions is that they should be small. The
second rule of functions is that they should be smaller than
that.” (Clean Code, Chapter 3: Functions)
“The first rule of classes is that they should be small. The
second rule of classes is that they should be smaller than
that.” (Clean Code, Chapter 10: Classes)
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 16/33
Single Responsibility Principle
The Single-Responsibility Principle is one of the simplest
principles but one of the most difficult to get right.
Recommendation
“The first rule of functions is that they should be small. The
second rule of functions is that they should be smaller than
that.” (Clean Code, Chapter 3: Functions)
“The first rule of classes is that they should be small. The
second rule of classes is that they should be smaller than
that.” (Clean Code, Chapter 10: Classes)
With functions we measured size by counting physical lines.
With classes we count responsibilities.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 16/33
Open-Closed Principle
Intent:
Software entities (classes, modules, functions, etc.) should be
open for extension but closed for modification.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 17/33
Open-Closed Principle
Intent:
Software entities (classes, modules, functions, etc.) should be
open for extension but closed for modification.
“Open For Extension”
The behavior of the module can be extended.
We can make the module behave in new and different ways as the
requirements of the application change, or to meet the needs of new
applications.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 17/33
Open-Closed Principle
Intent:
Software entities (classes, modules, functions, etc.) should be
open for extension but closed for modification.
“Open For Extension”
The behavior of the module can be extended.
We can make the module behave in new and different ways as the
requirements of the application change, or to meet the needs of new
applications.
“Closed For Modification”
The source code of such a module is inviolate. No one is allowed to
make source code changes to it.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 17/33
Open-Closed Principle
Abstraction is the Key
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 18/33
Open-Closed Principle
Abstraction is the Key
Figure 3: Graph Editor (1)
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 18/33
Open-Closed Principle
Abstraction is the Key
Figure 4: Graph Editor (2)
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 19/33
Open-Closed Principle
Abstraction is the Key
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 20/33
Open-Closed Principle
Abstraction is the Key
Well designed code can be extended without modification
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 20/33
Open-Closed Principle
Abstraction is the Key
Well designed code can be extended without modification
In well designed program, new features are added by adding
new code, rather than by change old, already working code
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 20/33
Open-Closed Principle
Abstraction is the Key
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 21/33
Open-Closed Principle
Abstraction is the Key
What are the characteristics of the best inheritance
hierarchies?
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 21/33
Open-Closed Principle
Abstraction is the Key
What are the characteristics of the best inheritance
hierarchies?
Liskov’s Substitution Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 21/33
Liskov’s Substitution Principle
Barbara Liskov, “Data Abstraction and Hierarchy” (1988)
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
Liskov’s Substitution Principle
Barbara Liskov, “Data Abstraction and Hierarchy” (1988)
What is wanted here is something like the following substitution property:
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
Liskov’s Substitution Principle
Barbara Liskov, “Data Abstraction and Hierarchy” (1988)
What is wanted here is something like the following substitution property:
If for each object o1 of type S, there is an object o2 of type T
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
Liskov’s Substitution Principle
Barbara Liskov, “Data Abstraction and Hierarchy” (1988)
What is wanted here is something like the following substitution property:
If for each object o1 of type S, there is an object o2 of type T
such that
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
Liskov’s Substitution Principle
Barbara Liskov, “Data Abstraction and Hierarchy” (1988)
What is wanted here is something like the following substitution property:
If for each object o1 of type S, there is an object o2 of type T
such that
for all programs P defined in terms of T,
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
Liskov’s Substitution Principle
Barbara Liskov, “Data Abstraction and Hierarchy” (1988)
What is wanted here is something like the following substitution property:
If for each object o1 of type S, there is an object o2 of type T
such that
for all programs P defined in terms of T,
the behavior of P is unchanged
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
Liskov’s Substitution Principle
Barbara Liskov, “Data Abstraction and Hierarchy” (1988)
What is wanted here is something like the following substitution property:
If for each object o1 of type S, there is an object o2 of type T
such that
for all programs P defined in terms of T,
the behavior of P is unchanged
when o1 is substituted for o2
then S is a subtype of T.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
Liskov’s Substitution Principle
Robert Martin
Function that use pointers or references to base classes must be
able to use object of derived classes without knowing it.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 23/33
Liskov’s Substitution Principle
Robert Martin
Function that use pointers or references to base classes must be
able to use object of derived classes without knowing it.
Intent: Derived classes should be substitutable for base classes.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 23/33
Liskov’s Substitution Principle
Derived classes should be substitutable for base classes.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 24/33
Liskov’s Substitution Principle
Derived classes should be substitutable for base classes.
We can always write
BaseClass b = new DerivedClass();
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 24/33
Liskov’s Substitution Principle
Derived classes should be substitutable for base classes.
We can always write
BaseClass b = new DerivedClass();
Why would such a principle be made?
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 24/33
Liskov’s Substitution Principle
class Rectangle{
private int width;
private int height;
public setWidth(int width_in);
public setHeight(int height_in);
public int getWidth ();
public int getHeight ();
public int getArea( return width * height );
}
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 25/33
Liskov’s Substitution Principle
class Rectangle{
private int width;
private int height;
public setWidth(int width_in);
public setHeight(int height_in);
public int getWidth ();
public int getHeight ();
public int getArea( return width * height );
}
Clearly, a square is a rectangle for all normal intents and purposes.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 25/33
Liskov’s Substitution Principle
class Rectangle{
private int width;
private int height;
public setWidth(int width_in);
public setHeight(int height_in);
public int getWidth ();
public int getHeight ();
public int getArea( return width * height );
}
Clearly, a square is a rectangle for all normal intents and purposes.
class Square extends Rectangle{
// Code specific to square
}
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 25/33
Liskov’s Substitution Principle
class Rectangle{
private int width;
private int height;
public setWidth(int width_in);
public setHeight(int height_in);
public int getWidth ();
public int getHeight ();
public int getArea( return width * height );
}
Clearly, a square is a rectangle for all normal intents and purposes.
class Square extends Rectangle{
// Code specific to square
}
class RectangleFactory (){
public static Rectangle createRectangle (int type){
switch(type){
case 1: return new Rectangle ();
case 2: return new Square ();
}
}
}
Rectangle a = RectangelFactory :: createRectangle (2);
a.setWidth (10);
a.setHeight (5);
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 25/33
Liskov’s Substitution Principle
class Rectangle{
private int width;
private int height;
public setWidth(int width_in);
public setHeight(int height_in);
public int getWidth ();
public int getHeight ();
public int getArea( return width * height );
}
class Square extends Rectangle{
public setWidth(int width_in){
Rectangle :: setWidth(width_in);
Rectangle :: setHeight(width_in);
}
public setHeight(int height_in){
Rectangle :: setWidth(height_in);
Rectangle :: setHeight(height_in);
}
}
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 26/33
Liskov’s Substitution Principle
class Rectangle{
private int width;
private int height;
public setWidth(int width_in);
public setHeight(int height_in);
public int getWidth ();
public int getHeight ();
public int getArea( return width * height );
}
class Square extends Rectangle{
public setWidth(int width_in){
Rectangle :: setWidth(width_in);
Rectangle :: setHeight(width_in);
}
public setHeight(int height_in){
Rectangle :: setWidth(height_in);
Rectangle :: setHeight(height_in);
}
}
Rectangle a = RectangleFactory : createRectangle (2);
a.setWidth (10); // both width and height are set to 10
a.setHeight (5); //now , both width and height are 5
println(a.getArea ());
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 26/33
Liskov’s Substitution Principle
Violating LSP!
Changing the behavior of Width and Height properties in derived
class.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 27/33
Liskov’s Substitution Principle
Violating LSP!
Changing the behavior of Width and Height properties in derived
class.
Consider postcondition of Rectangle::setWidth(int width in):
assert (( width == width_in) && (height == old.height))
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 27/33
Liskov’s Substitution Principle
Design by Contract: Introduced by Bertrand Meyer, in Object
Oriented Software Construction, 1988.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 28/33
Liskov’s Substitution Principle
Design by Contract: Introduced by Bertrand Meyer, in Object
Oriented Software Construction, 1988.
Preconditions: The preconditions must be true in order for the
method to execute.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 28/33
Liskov’s Substitution Principle
Design by Contract: Introduced by Bertrand Meyer, in Object
Oriented Software Construction, 1988.
Preconditions: The preconditions must be true in order for the
method to execute.
Postconditions: Upon completion, the method guarantees
that the postconditions will be true.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 28/33
Liskov’s Substitution Principle
Design by Contract: Introduced by Bertrand Meyer, in Object
Oriented Software Construction, 1988.
Preconditions: The preconditions must be true in order for the
method to execute.
Postconditions: Upon completion, the method guarantees
that the postconditions will be true.
...when redefining a routine [in a derivative], you may only
replace its precondition by a weaker one, and its postcondition
by a stronger one.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 28/33
Dependency Inversion Principle
Intent:
High Level Modules should not depend upon low level
modules. Both should be depend upon abstractions.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 29/33
Dependency Inversion Principle
Intent:
High Level Modules should not depend upon low level
modules. Both should be depend upon abstractions.
Abstractions should not depend upon details. Details should
depend upon abstractions.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 29/33
Dependency Inversion Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 30/33
Dependency Inversion Principle
Figure 5: The Copy Program
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 30/33
Interface Segregation Principle
Intent:
The clients should not be forced to depend upon interfaces that
they do not use.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 31/33
Interface Segregation Principle
Intent:
The clients should not be forced to depend upon interfaces that
they do not use.
Another definition:
Many client specific interfaces are better than one general
purpose interface.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 31/33
Summary
Single Responsibility Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
Summary
Single Responsibility Principle
Open-Closed Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
Summary
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
Summary
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
Summary
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
Summary
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
A principle is only a principle. In order to avoid bad design and
make a flexible design, we should spend a lot of time and effort.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
Thank you for watching!
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 33/33

More Related Content

Similar to Object Oriented Design Principle

Evolutionary Design - NewCrafts Paris 18 May 2018
Evolutionary Design - NewCrafts Paris 18 May 2018Evolutionary Design - NewCrafts Paris 18 May 2018
Evolutionary Design - NewCrafts Paris 18 May 2018Adi Bolboaca
 
Design Patterns (by Joel Funu at DevCongress 2013)
Design Patterns (by Joel Funu at DevCongress 2013)Design Patterns (by Joel Funu at DevCongress 2013)
Design Patterns (by Joel Funu at DevCongress 2013)DevCongress
 
PATTERNS01 - An Introduction to Design Patterns
PATTERNS01 - An Introduction to Design PatternsPATTERNS01 - An Introduction to Design Patterns
PATTERNS01 - An Introduction to Design PatternsMichael Heron
 
PATTERNS05 - Guidelines for Choosing a Design Pattern
PATTERNS05 - Guidelines for Choosing a Design PatternPATTERNS05 - Guidelines for Choosing a Design Pattern
PATTERNS05 - Guidelines for Choosing a Design PatternMichael Heron
 
Learning Process and Innovation Theories
Learning Process and Innovation TheoriesLearning Process and Innovation Theories
Learning Process and Innovation TheoriesHiroki MIZOKAMI
 
Engineering Outside the Box (presented at Ewha Woman's University, 13/11/14)
Engineering Outside the Box   (presented at Ewha Woman's University, 13/11/14)Engineering Outside the Box   (presented at Ewha Woman's University, 13/11/14)
Engineering Outside the Box (presented at Ewha Woman's University, 13/11/14)Christopher Congleton
 
Dan Lockton Behavior Design Amsterdam New Year 2016
Dan Lockton Behavior Design Amsterdam New Year 2016Dan Lockton Behavior Design Amsterdam New Year 2016
Dan Lockton Behavior Design Amsterdam New Year 2016Behavior Design AMS
 
Design Fixation for UX Professionals in 10 Minutes or Less! (Dec. 11, 2013)
Design Fixation for UX Professionals in 10 Minutes or Less! (Dec. 11, 2013)Design Fixation for UX Professionals in 10 Minutes or Less! (Dec. 11, 2013)
Design Fixation for UX Professionals in 10 Minutes or Less! (Dec. 11, 2013)robyoumans
 
Inclusive design playbook
Inclusive design playbookInclusive design playbook
Inclusive design playbookYilin Zeng
 
Summary Of Defending Against The Indefensible Essay
Summary Of Defending Against The Indefensible EssaySummary Of Defending Against The Indefensible Essay
Summary Of Defending Against The Indefensible EssayBrenda Zerr
 
Simplicty Appreciation 101
Simplicty Appreciation 101Simplicty Appreciation 101
Simplicty Appreciation 101Craig Jones
 
Instructional Design basics
Instructional Design basicsInstructional Design basics
Instructional Design basicsChris Fuller
 
Design Patterns Story
Design Patterns StoryDesign Patterns Story
Design Patterns StoryArun A
 
Design Thinking Action Lab - How Do You Solve Problems
Design Thinking Action Lab - How Do You Solve ProblemsDesign Thinking Action Lab - How Do You Solve Problems
Design Thinking Action Lab - How Do You Solve ProblemsShamik Chowdhury
 
A Clash of Concerns: Applying Design Thinking to Social Dilemmas
A Clash of Concerns: Applying Design Thinking to Social Dilemmas A Clash of Concerns: Applying Design Thinking to Social Dilemmas
A Clash of Concerns: Applying Design Thinking to Social Dilemmas Geoffrey Dorne
 
Module 2 design patterns-2
Module 2   design patterns-2Module 2   design patterns-2
Module 2 design patterns-2Ankit Dubey
 

Similar to Object Oriented Design Principle (20)

Crafting Great Code
Crafting Great CodeCrafting Great Code
Crafting Great Code
 
Evolutionary Design - NewCrafts Paris 18 May 2018
Evolutionary Design - NewCrafts Paris 18 May 2018Evolutionary Design - NewCrafts Paris 18 May 2018
Evolutionary Design - NewCrafts Paris 18 May 2018
 
Design Patterns (by Joel Funu at DevCongress 2013)
Design Patterns (by Joel Funu at DevCongress 2013)Design Patterns (by Joel Funu at DevCongress 2013)
Design Patterns (by Joel Funu at DevCongress 2013)
 
PATTERNS01 - An Introduction to Design Patterns
PATTERNS01 - An Introduction to Design PatternsPATTERNS01 - An Introduction to Design Patterns
PATTERNS01 - An Introduction to Design Patterns
 
PATTERNS05 - Guidelines for Choosing a Design Pattern
PATTERNS05 - Guidelines for Choosing a Design PatternPATTERNS05 - Guidelines for Choosing a Design Pattern
PATTERNS05 - Guidelines for Choosing a Design Pattern
 
Learning Process and Innovation Theories
Learning Process and Innovation TheoriesLearning Process and Innovation Theories
Learning Process and Innovation Theories
 
SN- Lecture 3
SN- Lecture 3SN- Lecture 3
SN- Lecture 3
 
Engineering Outside the Box (presented at Ewha Woman's University, 13/11/14)
Engineering Outside the Box   (presented at Ewha Woman's University, 13/11/14)Engineering Outside the Box   (presented at Ewha Woman's University, 13/11/14)
Engineering Outside the Box (presented at Ewha Woman's University, 13/11/14)
 
Dan Lockton Behavior Design Amsterdam New Year 2016
Dan Lockton Behavior Design Amsterdam New Year 2016Dan Lockton Behavior Design Amsterdam New Year 2016
Dan Lockton Behavior Design Amsterdam New Year 2016
 
Clean code
Clean codeClean code
Clean code
 
Design Fixation for UX Professionals in 10 Minutes or Less! (Dec. 11, 2013)
Design Fixation for UX Professionals in 10 Minutes or Less! (Dec. 11, 2013)Design Fixation for UX Professionals in 10 Minutes or Less! (Dec. 11, 2013)
Design Fixation for UX Professionals in 10 Minutes or Less! (Dec. 11, 2013)
 
Inclusive design playbook
Inclusive design playbookInclusive design playbook
Inclusive design playbook
 
Summary Of Defending Against The Indefensible Essay
Summary Of Defending Against The Indefensible EssaySummary Of Defending Against The Indefensible Essay
Summary Of Defending Against The Indefensible Essay
 
Simplicty Appreciation 101
Simplicty Appreciation 101Simplicty Appreciation 101
Simplicty Appreciation 101
 
Instructional Design basics
Instructional Design basicsInstructional Design basics
Instructional Design basics
 
Unit iii design patterns 9
Unit iii design patterns 9Unit iii design patterns 9
Unit iii design patterns 9
 
Design Patterns Story
Design Patterns StoryDesign Patterns Story
Design Patterns Story
 
Design Thinking Action Lab - How Do You Solve Problems
Design Thinking Action Lab - How Do You Solve ProblemsDesign Thinking Action Lab - How Do You Solve Problems
Design Thinking Action Lab - How Do You Solve Problems
 
A Clash of Concerns: Applying Design Thinking to Social Dilemmas
A Clash of Concerns: Applying Design Thinking to Social Dilemmas A Clash of Concerns: Applying Design Thinking to Social Dilemmas
A Clash of Concerns: Applying Design Thinking to Social Dilemmas
 
Module 2 design patterns-2
Module 2   design patterns-2Module 2   design patterns-2
Module 2 design patterns-2
 

Recently uploaded

Scanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsScanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsRizwan Syed
 
How to convert PDF to text with Nanonets
How to convert PDF to text with NanonetsHow to convert PDF to text with Nanonets
How to convert PDF to text with Nanonetsnaman860154
 
FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | DelhiFULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhisoniya singh
 
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationBeyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationSafe Software
 
Pigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions
 
Unleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubUnleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubKalema Edgar
 
CloudStudio User manual (basic edition):
CloudStudio User manual (basic edition):CloudStudio User manual (basic edition):
CloudStudio User manual (basic edition):comworks
 
Understanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitectureUnderstanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitecturePixlogix Infotech
 
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Enterprise Knowledge
 
Transcript: New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024Transcript: New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024BookNet Canada
 
Advanced Test Driven-Development @ php[tek] 2024
Advanced Test Driven-Development @ php[tek] 2024Advanced Test Driven-Development @ php[tek] 2024
Advanced Test Driven-Development @ php[tek] 2024Scott Keck-Warren
 
Unlocking the Potential of the Cloud for IBM Power Systems
Unlocking the Potential of the Cloud for IBM Power SystemsUnlocking the Potential of the Cloud for IBM Power Systems
Unlocking the Potential of the Cloud for IBM Power SystemsPrecisely
 
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...Patryk Bandurski
 
SIEMENS: RAPUNZEL – A Tale About Knowledge Graph
SIEMENS: RAPUNZEL – A Tale About Knowledge GraphSIEMENS: RAPUNZEL – A Tale About Knowledge Graph
SIEMENS: RAPUNZEL – A Tale About Knowledge GraphNeo4j
 
Key Features Of Token Development (1).pptx
Key  Features Of Token  Development (1).pptxKey  Features Of Token  Development (1).pptx
Key Features Of Token Development (1).pptxLBM Solutions
 
Injustice - Developers Among Us (SciFiDevCon 2024)
Injustice - Developers Among Us (SciFiDevCon 2024)Injustice - Developers Among Us (SciFiDevCon 2024)
Injustice - Developers Among Us (SciFiDevCon 2024)Allon Mureinik
 

Recently uploaded (20)

Scanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsScanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL Certs
 
How to convert PDF to text with Nanonets
How to convert PDF to text with NanonetsHow to convert PDF to text with Nanonets
How to convert PDF to text with Nanonets
 
FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | DelhiFULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
 
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationBeyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
 
DMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special EditionDMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special Edition
 
Pigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food Manufacturing
 
Unleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubUnleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding Club
 
CloudStudio User manual (basic edition):
CloudStudio User manual (basic edition):CloudStudio User manual (basic edition):
CloudStudio User manual (basic edition):
 
Understanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitectureUnderstanding the Laravel MVC Architecture
Understanding the Laravel MVC Architecture
 
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024
 
08448380779 Call Girls In Friends Colony Women Seeking Men
08448380779 Call Girls In Friends Colony Women Seeking Men08448380779 Call Girls In Friends Colony Women Seeking Men
08448380779 Call Girls In Friends Colony Women Seeking Men
 
E-Vehicle_Hacking_by_Parul Sharma_null_owasp.pptx
E-Vehicle_Hacking_by_Parul Sharma_null_owasp.pptxE-Vehicle_Hacking_by_Parul Sharma_null_owasp.pptx
E-Vehicle_Hacking_by_Parul Sharma_null_owasp.pptx
 
Transcript: New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024Transcript: New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024
 
Advanced Test Driven-Development @ php[tek] 2024
Advanced Test Driven-Development @ php[tek] 2024Advanced Test Driven-Development @ php[tek] 2024
Advanced Test Driven-Development @ php[tek] 2024
 
Unlocking the Potential of the Cloud for IBM Power Systems
Unlocking the Potential of the Cloud for IBM Power SystemsUnlocking the Potential of the Cloud for IBM Power Systems
Unlocking the Potential of the Cloud for IBM Power Systems
 
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
 
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
 
SIEMENS: RAPUNZEL – A Tale About Knowledge Graph
SIEMENS: RAPUNZEL – A Tale About Knowledge GraphSIEMENS: RAPUNZEL – A Tale About Knowledge Graph
SIEMENS: RAPUNZEL – A Tale About Knowledge Graph
 
Key Features Of Token Development (1).pptx
Key  Features Of Token  Development (1).pptxKey  Features Of Token  Development (1).pptx
Key Features Of Token Development (1).pptx
 
Injustice - Developers Among Us (SciFiDevCon 2024)
Injustice - Developers Among Us (SciFiDevCon 2024)Injustice - Developers Among Us (SciFiDevCon 2024)
Injustice - Developers Among Us (SciFiDevCon 2024)
 

Object Oriented Design Principle

  • 1. Mental Log - Week 3 Object Oriented Design Principles Class Design Principles Dinh Hoang Long Mental Log Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 1/33
  • 2. Outline Overview Bad Design Class Design Principles Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Interface Segregation Principle Dependency Inversion Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 2/33
  • 3. Overview Design Principles “Software design principles represent a set of guidelines that helps us to avoid having a bad design.” Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
  • 4. Overview Design Principles “Software design principles represent a set of guidelines that helps us to avoid having a bad design.” Identified by Robert C. Martin (Uncle Bob) in the early 2000s. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
  • 5. Overview Design Principles “Software design principles represent a set of guidelines that helps us to avoid having a bad design.” Identified by Robert C. Martin (Uncle Bob) in the early 2000s. Gathered in ”Agile Software Development: Principles, Patterns, and Practices” (2003). Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
  • 6. Overview Design Principles “Software design principles represent a set of guidelines that helps us to avoid having a bad design.” Identified by Robert C. Martin (Uncle Bob) in the early 2000s. Gathered in ”Agile Software Development: Principles, Patterns, and Practices” (2003). Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
  • 7. Overview Design Principles “Software design principles represent a set of guidelines that helps us to avoid having a bad design.” Identified by Robert C. Martin (Uncle Bob) in the early 2000s. Gathered in ”Agile Software Development: Principles, Patterns, and Practices” (2003). Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 3/33
  • 8. Object Oriented Design Principles Class Design Principles (5) Package Cohesion Principles (3) Package Coupling Principles (3) Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 4/33
  • 9. Object Oriented Design Principles Clas Design Principles Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Interface Segregation Principle Dependency Inversion Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 5/33
  • 10. Object Oriented Design Principles Package Cohesion Principles Release Reuse Equivalency Principle Common Closure Principle Common Reuse Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 6/33
  • 11. Object Oriented Design Principles Package Coupling principles Acyclic Dependencies Principle Stable Dependencies Principle Stable Abstractions Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 7/33
  • 12. Bad Code Rigidity - It is hard to change because every change affects too many other parts of the system. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 8/33
  • 13. Bad Code Rigidity - It is hard to change because every change affects too many other parts of the system. Fragility - When you make a change, unexpected parts of the system break. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 8/33
  • 14. Bad Code Rigidity - It is hard to change because every change affects too many other parts of the system. Fragility - When you make a change, unexpected parts of the system break. Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 8/33
  • 15. Class Design Principles Single Responsibility Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
  • 16. Class Design Principles Single Responsibility Principle Open-Closed Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
  • 17. Class Design Principles Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
  • 18. Class Design Principles Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Interface Segregation Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
  • 19. Class Design Principles Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Interface Segregation Principle Dependency Inversion Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 9/33
  • 20. Class Design Principles Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Dependency Inversion Principle Interface Segregation Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 10/33
  • 21. Single Responsibility Principle Figure 1: Real World Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 11/33
  • 22. Single Responsibility Principle Figure 1: Real World Intent: “A class should have only one reason to change.” Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 11/33
  • 23. Single Responsibility Principle Another Definition: “Every software module should have only one reason to change” Software Module - Class, Function,... Reason to change - Responsibility Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 12/33
  • 24. Single Responsibility Principle Question Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
  • 25. Single Responsibility Principle Question A class will have single responsibility. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
  • 26. Single Responsibility Principle Question A class will have single responsibility. A function will have single responsibility. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
  • 27. Single Responsibility Principle Question A class will have single responsibility. A function will have single responsibility. A class will have more than one function. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
  • 28. Single Responsibility Principle Question A class will have single responsibility. A function will have single responsibility. A class will have more than one function. → A class will have more than one responsibility? Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 13/33
  • 29. Single Responsibility Principle Figure 2: Factory Implementation Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 14/33
  • 30. Single Responsibility Principle Drawbacks? The so called ’Class Explosion’. Our application may end up with too many classes to manage. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 15/33
  • 31. Single Responsibility Principle Drawbacks? The so called ’Class Explosion’. Our application may end up with too many classes to manage. There are a lot of class, so when I want to change something, I can’t find the code I need to change. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 15/33
  • 32. Single Responsibility Principle The Single-Responsibility Principle is one of the simplest principles but one of the most difficult to get right. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 16/33
  • 33. Single Responsibility Principle The Single-Responsibility Principle is one of the simplest principles but one of the most difficult to get right. Recommendation “The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.” (Clean Code, Chapter 3: Functions) Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 16/33
  • 34. Single Responsibility Principle The Single-Responsibility Principle is one of the simplest principles but one of the most difficult to get right. Recommendation “The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.” (Clean Code, Chapter 3: Functions) “The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that.” (Clean Code, Chapter 10: Classes) Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 16/33
  • 35. Single Responsibility Principle The Single-Responsibility Principle is one of the simplest principles but one of the most difficult to get right. Recommendation “The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.” (Clean Code, Chapter 3: Functions) “The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that.” (Clean Code, Chapter 10: Classes) With functions we measured size by counting physical lines. With classes we count responsibilities. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 16/33
  • 36. Open-Closed Principle Intent: Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 17/33
  • 37. Open-Closed Principle Intent: Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. “Open For Extension” The behavior of the module can be extended. We can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 17/33
  • 38. Open-Closed Principle Intent: Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. “Open For Extension” The behavior of the module can be extended. We can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications. “Closed For Modification” The source code of such a module is inviolate. No one is allowed to make source code changes to it. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 17/33
  • 39. Open-Closed Principle Abstraction is the Key Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 18/33
  • 40. Open-Closed Principle Abstraction is the Key Figure 3: Graph Editor (1) Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 18/33
  • 41. Open-Closed Principle Abstraction is the Key Figure 4: Graph Editor (2) Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 19/33
  • 42. Open-Closed Principle Abstraction is the Key Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 20/33
  • 43. Open-Closed Principle Abstraction is the Key Well designed code can be extended without modification Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 20/33
  • 44. Open-Closed Principle Abstraction is the Key Well designed code can be extended without modification In well designed program, new features are added by adding new code, rather than by change old, already working code Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 20/33
  • 45. Open-Closed Principle Abstraction is the Key Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 21/33
  • 46. Open-Closed Principle Abstraction is the Key What are the characteristics of the best inheritance hierarchies? Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 21/33
  • 47. Open-Closed Principle Abstraction is the Key What are the characteristics of the best inheritance hierarchies? Liskov’s Substitution Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 21/33
  • 48. Liskov’s Substitution Principle Barbara Liskov, “Data Abstraction and Hierarchy” (1988) Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
  • 49. Liskov’s Substitution Principle Barbara Liskov, “Data Abstraction and Hierarchy” (1988) What is wanted here is something like the following substitution property: Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
  • 50. Liskov’s Substitution Principle Barbara Liskov, “Data Abstraction and Hierarchy” (1988) What is wanted here is something like the following substitution property: If for each object o1 of type S, there is an object o2 of type T Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
  • 51. Liskov’s Substitution Principle Barbara Liskov, “Data Abstraction and Hierarchy” (1988) What is wanted here is something like the following substitution property: If for each object o1 of type S, there is an object o2 of type T such that Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
  • 52. Liskov’s Substitution Principle Barbara Liskov, “Data Abstraction and Hierarchy” (1988) What is wanted here is something like the following substitution property: If for each object o1 of type S, there is an object o2 of type T such that for all programs P defined in terms of T, Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
  • 53. Liskov’s Substitution Principle Barbara Liskov, “Data Abstraction and Hierarchy” (1988) What is wanted here is something like the following substitution property: If for each object o1 of type S, there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
  • 54. Liskov’s Substitution Principle Barbara Liskov, “Data Abstraction and Hierarchy” (1988) What is wanted here is something like the following substitution property: If for each object o1 of type S, there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
  • 55. Liskov’s Substitution Principle Robert Martin Function that use pointers or references to base classes must be able to use object of derived classes without knowing it. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 23/33
  • 56. Liskov’s Substitution Principle Robert Martin Function that use pointers or references to base classes must be able to use object of derived classes without knowing it. Intent: Derived classes should be substitutable for base classes. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 23/33
  • 57. Liskov’s Substitution Principle Derived classes should be substitutable for base classes. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 24/33
  • 58. Liskov’s Substitution Principle Derived classes should be substitutable for base classes. We can always write BaseClass b = new DerivedClass(); Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 24/33
  • 59. Liskov’s Substitution Principle Derived classes should be substitutable for base classes. We can always write BaseClass b = new DerivedClass(); Why would such a principle be made? Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 24/33
  • 60. Liskov’s Substitution Principle class Rectangle{ private int width; private int height; public setWidth(int width_in); public setHeight(int height_in); public int getWidth (); public int getHeight (); public int getArea( return width * height ); } Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 25/33
  • 61. Liskov’s Substitution Principle class Rectangle{ private int width; private int height; public setWidth(int width_in); public setHeight(int height_in); public int getWidth (); public int getHeight (); public int getArea( return width * height ); } Clearly, a square is a rectangle for all normal intents and purposes. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 25/33
  • 62. Liskov’s Substitution Principle class Rectangle{ private int width; private int height; public setWidth(int width_in); public setHeight(int height_in); public int getWidth (); public int getHeight (); public int getArea( return width * height ); } Clearly, a square is a rectangle for all normal intents and purposes. class Square extends Rectangle{ // Code specific to square } Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 25/33
  • 63. Liskov’s Substitution Principle class Rectangle{ private int width; private int height; public setWidth(int width_in); public setHeight(int height_in); public int getWidth (); public int getHeight (); public int getArea( return width * height ); } Clearly, a square is a rectangle for all normal intents and purposes. class Square extends Rectangle{ // Code specific to square } class RectangleFactory (){ public static Rectangle createRectangle (int type){ switch(type){ case 1: return new Rectangle (); case 2: return new Square (); } } } Rectangle a = RectangelFactory :: createRectangle (2); a.setWidth (10); a.setHeight (5); Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 25/33
  • 64. Liskov’s Substitution Principle class Rectangle{ private int width; private int height; public setWidth(int width_in); public setHeight(int height_in); public int getWidth (); public int getHeight (); public int getArea( return width * height ); } class Square extends Rectangle{ public setWidth(int width_in){ Rectangle :: setWidth(width_in); Rectangle :: setHeight(width_in); } public setHeight(int height_in){ Rectangle :: setWidth(height_in); Rectangle :: setHeight(height_in); } } Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 26/33
  • 65. Liskov’s Substitution Principle class Rectangle{ private int width; private int height; public setWidth(int width_in); public setHeight(int height_in); public int getWidth (); public int getHeight (); public int getArea( return width * height ); } class Square extends Rectangle{ public setWidth(int width_in){ Rectangle :: setWidth(width_in); Rectangle :: setHeight(width_in); } public setHeight(int height_in){ Rectangle :: setWidth(height_in); Rectangle :: setHeight(height_in); } } Rectangle a = RectangleFactory : createRectangle (2); a.setWidth (10); // both width and height are set to 10 a.setHeight (5); //now , both width and height are 5 println(a.getArea ()); Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 26/33
  • 66. Liskov’s Substitution Principle Violating LSP! Changing the behavior of Width and Height properties in derived class. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 27/33
  • 67. Liskov’s Substitution Principle Violating LSP! Changing the behavior of Width and Height properties in derived class. Consider postcondition of Rectangle::setWidth(int width in): assert (( width == width_in) && (height == old.height)) Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 27/33
  • 68. Liskov’s Substitution Principle Design by Contract: Introduced by Bertrand Meyer, in Object Oriented Software Construction, 1988. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 28/33
  • 69. Liskov’s Substitution Principle Design by Contract: Introduced by Bertrand Meyer, in Object Oriented Software Construction, 1988. Preconditions: The preconditions must be true in order for the method to execute. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 28/33
  • 70. Liskov’s Substitution Principle Design by Contract: Introduced by Bertrand Meyer, in Object Oriented Software Construction, 1988. Preconditions: The preconditions must be true in order for the method to execute. Postconditions: Upon completion, the method guarantees that the postconditions will be true. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 28/33
  • 71. Liskov’s Substitution Principle Design by Contract: Introduced by Bertrand Meyer, in Object Oriented Software Construction, 1988. Preconditions: The preconditions must be true in order for the method to execute. Postconditions: Upon completion, the method guarantees that the postconditions will be true. ...when redefining a routine [in a derivative], you may only replace its precondition by a weaker one, and its postcondition by a stronger one. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 28/33
  • 72. Dependency Inversion Principle Intent: High Level Modules should not depend upon low level modules. Both should be depend upon abstractions. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 29/33
  • 73. Dependency Inversion Principle Intent: High Level Modules should not depend upon low level modules. Both should be depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 29/33
  • 74. Dependency Inversion Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 30/33
  • 75. Dependency Inversion Principle Figure 5: The Copy Program Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 30/33
  • 76. Interface Segregation Principle Intent: The clients should not be forced to depend upon interfaces that they do not use. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 31/33
  • 77. Interface Segregation Principle Intent: The clients should not be forced to depend upon interfaces that they do not use. Another definition: Many client specific interfaces are better than one general purpose interface. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 31/33
  • 78. Summary Single Responsibility Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
  • 79. Summary Single Responsibility Principle Open-Closed Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
  • 80. Summary Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
  • 81. Summary Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Interface Segregation Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
  • 82. Summary Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Interface Segregation Principle Dependency Inversion Principle Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
  • 83. Summary Single Responsibility Principle Open-Closed Principle Liskov’s Substitution Principle Interface Segregation Principle Dependency Inversion Principle A principle is only a principle. In order to avoid bad design and make a flexible design, we should spend a lot of time and effort. Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 32/33
  • 84. Thank you for watching! Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 33/33