Object Oriented Design Principle

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
Single Responsibility Principle
Open-Closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Overview
Design Principles
“Software design principles represent a set of guidelines that
helps us to avoid having a bad design.”

Overview
Design Principles
Identiﬁed by Robert C. Martin (Uncle Bob) in the early 2000s.

Overview
Design Principles
Identiﬁed by Robert C. Martin (Uncle Bob) in the early 2000s.
Gathered in ”Agile Software Development: Principles,
Patterns, and Practices” (2003).

Class Design Principles (5)
Package Cohesion Principles (3)
Package Coupling Principles (3)

Clas Design Principles

Package Cohesion Principles
Release Reuse Equivalency Principle
Common Closure Principle
Common Reuse Principle

Package Coupling principles
Acyclic Dependencies Principle
Stable Dependencies Principle
Stable Abstractions Principle

Bad Code
Rigidity - It is hard to change because every change aﬀects
too many other parts of the system.

Bad Code
Fragility - When you make a change, unexpected parts of the
system break.

Bad Code
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.

Figure 1: Real World

Figure 1: Real World
Intent:
“A class should have only one reason to change.”

Another Deﬁnition:
“Every software module should have only one reason to change”
Software Module - Class, Function,...
Reason to change - Responsibility

Question

Question
A class will have single responsibility.

Question
A function will have single responsibility.

Question
A class will have more than one function.

Question
A class will have more than one function.
→ A class will have more than one responsibility?

Figure 2: Factory Implementation

Drawbacks?
The so called ’Class Explosion’. Our application may end
up with too many classes to manage.

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 ﬁnd the code I need to change.

The Single-Responsibility Principle is one of the simplest
principles but one of the most diﬃcult to get right.

Recommendation
“The ﬁrst 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)

Recommendation
“The ﬁrst 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)

Recommendation
“The ﬁrst 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.

Intent:
Software entities (classes, modules, functions, etc.) should be
open for extension but closed for modiﬁcation.

Intent:
“Open For Extension”
The behavior of the module can be extended.
We can make the module behave in new and diﬀerent ways as the
requirements of the application change, or to meet the needs of new
applications.

Intent:
“Open For Extension”
The behavior of the module can be extended.
We can make the module behave in new and diﬀerent ways as the
requirements of the application change, or to meet the needs of new
applications.
“Closed For Modiﬁcation”
The source code of such a module is inviolate. No one is allowed to
make source code changes to it.

Abstraction is the Key

Figure 3: Graph Editor (1)

Figure 4: Graph Editor (2)

Well designed code can be extended without modiﬁcation

Well designed code can be extended without modiﬁcation
In well designed program, new features are added by adding
new code, rather than by change old, already working code

What are the characteristics of the best inheritance
hierarchies?

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

such that
for all programs P deﬁned in terms of T,

such that
the behavior of P is unchanged

such that
the behavior of P is unchanged
when o1 is substituted for o2
then S is a subtype of T.

Robert Martin
Function that use pointers or references to base classes must be
able to use object of derived classes without knowing it.

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.

Derived classes should be substitutable for base classes.

We can always write
BaseClass b = new DerivedClass();

We can always write
BaseClass b = new DerivedClass();
Why would such a principle be made?

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 Rectangle{
private int width;
private int height;
}
Clearly, a square is a rectangle for all normal intents and purposes.

class Rectangle{
private int width;
private int height;
}
class Square extends Rectangle{
// Code specific to square
}

class Rectangle{
private int width;
private int height;
}
// 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);

class Rectangle{
private int width;
private int height;
}
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);
}
}

class Rectangle{
private int width;
private int height;
}
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 ());

Violating LSP!
Changing the behavior of Width and Height properties in derived
class.

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

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.

method to execute.
Postconditions: Upon completion, the method guarantees
that the postconditions will be true.

method to execute.
Postconditions: Upon completion, the method guarantees
that the postconditions will be true.
...when redeﬁning a routine [in a derivative], you may only
replace its precondition by a weaker one, and its postcondition
by a stronger one.

Intent:
High Level Modules should not depend upon low level
modules. Both should be depend upon abstractions.

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.

Figure 5: The Copy Program

Intent:
The clients should not be forced to depend upon interfaces that
they do not use.

Intent:
The clients should not be forced to depend upon interfaces that
they do not use.
Another deﬁnition:
Many client speciﬁc interfaces are better than one general
purpose interface.

Summary

Summary
A principle is only a principle. In order to avoid bad design and
make a ﬂexible design, we should spend a lot of time and eﬀort.

Thank you for watching!

Object Oriented Design Principle

More Related Content

Similar to Object Oriented Design Principle

Recently uploaded

Object Oriented Design Principle