Object Oriented Design Principle

Mental Log - Week 3

Object Oriented Design PrinciplesClass 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 PrincipleOpen-Closed PrincipleLiskov’s Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle


Overview

Design Principles

“Software design principles represent a set of guidelines thathelps 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).


Overview

Design Principles





Overview

Design Principles





Overview

Design Principles





Overview

Design Principles





Object Oriented Design Principles

Class Design Principles (5)

Package Cohesion Principles (3)

Package Coupling Principles (3)



Clas Design Principles

Single Responsibility Principle

Open-Closed Principle

Liskov’s Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle



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 affectstoo many other parts of the system.

Fragility - When you make a change, unexpected parts of thesystem break.

Immobility - It is hard to reuse in another application becauseit cannot be disentangled from the current application.


Bad Code





Bad Code
















































Figure 1: Real World

Intent:“A class should have only one reason to change.”



Figure 1: Real World

Intent:“A class should have only one reason to change.”



Another Definition:“Every software module should have only one reason to change”

Software Module - Class, Function,...

Reason to change - Responsibility



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?



Question







Question







Question







Question







Figure 2: Factory Implementation



Drawbacks?

The so called ’Class Explosion’. Our application may endup with too many classes to manage.

There are a lot of class, so when I want to changesomething, I can’t find the code I need to change.



Drawbacks?

The so called ’Class Explosion’. Our application may endup with too many classes to manage.

There are a lot of class, so when I want to changesomething, I can’t find the code I need to change.



The Single-Responsibility Principle is one of the simplestprinciples but one of the most difficult to get right.

Recommendation

“The first rule of functions is that they should be small. Thesecond rule of functions is that they should be smaller thanthat.” (Clean Code, Chapter 3: Functions)“The first rule of classes is that they should be small. Thesecond rule of classes is that they should be smaller thanthat.” (Clean Code, Chapter 10: Classes)With functions we measured size by counting physical lines.With classes we count responsibilities.




Recommendation

“The first rule of functions is that they should be small. Thesecond rule of functions is that they should be smaller thanthat.” (Clean Code, Chapter 3: Functions)

“The first rule of classes is that they should be small. Thesecond rule of classes is that they should be smaller thanthat.” (Clean Code, Chapter 10: Classes)With functions we measured size by counting physical lines.With classes we count responsibilities.




Recommendation

“The first rule of functions is that they should be small. Thesecond rule of functions is that they should be smaller thanthat.” (Clean Code, Chapter 3: Functions)“The first rule of classes is that they should be small. Thesecond rule of classes is that they should be smaller thanthat.” (Clean Code, Chapter 10: Classes)

With functions we measured size by counting physical lines.With classes we count responsibilities.




Recommendation

“The first rule of functions is that they should be small. Thesecond rule of functions is that they should be smaller thanthat.” (Clean Code, Chapter 3: Functions)“The first rule of classes is that they should be small. Thesecond rule of classes is that they should be smaller thanthat.” (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 modification.

“Open For Extension”The behavior of the module can be extended.We can make the module behave in new and different ways as therequirements of the application change, or to meet the needs of newapplications.

“Closed For Modification”The source code of such a module is inviolate. No one is allowed tomake source code changes to it.















Abstraction is the Key

Figure 3: Graph Editor (1)












Well designed code can be extended without modification

In well designed program, new features are added by addingnew code, rather than by change old, already working code














What are the characteristics of the best inheritancehierarchies?














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













If for each object o1 of type S, there is an object o2 of type T

such thatfor all programs P defined in terms of T,

the behavior of P is unchangedwhen o1 is substituted for o2















for all programs P defined in terms of T,

the behavior of P is unchangedwhen o1 is substituted for o2




















Robert MartinFunction 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.



Robert MartinFunction 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 writeBaseClass 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 );

}

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



class Rectangle{

private int width;

private int height;






}




}



switch(type){



}

}

}


a.setWidth (10);

a.setHeight (5);



class Rectangle{

private int width;

private int height;






}




}



switch(type){



}

}

}


a.setWidth (10);

a.setHeight (5);



class Rectangle{

private int width;

private int height;






}




}



switch(type){



}

}

}


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

}

}

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



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

Consider postcondition of Rectangle::setWidth(int width in):

assert ((width == width_in) && (height == old.height))



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

Consider postcondition of Rectangle::setWidth(int width in):

assert ((width == width_in) && (height == old.height))



Design by Contract: Introduced by Bertrand Meyer, in ObjectOriented Software Construction, 1988.

Preconditions: The preconditions must be true in order for themethod to execute.

Postconditions: Upon completion, the method guaranteesthat the postconditions will be true.

...when redefining a routine [in a derivative], you may onlyreplace its precondition by a weaker one, and its postconditionby a stronger one.





















Intent:

High Level Modules should not depend upon low levelmodules. Both should be depend upon abstractions.

Abstractions should not depend upon details. Details shoulddepend upon abstractions.



Intent:

High Level Modules should not depend upon low levelmodules. Both should be depend upon abstractions.

Abstractions should not depend upon details. Details shoulddepend upon abstractions.



Figure 5: The Copy Program



Figure 5: The Copy Program



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.



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.


Summary






A principle is only a principle. In order to avoid bad design andmake a flexible design, we should spend a lot of time and effort.


Summary








Summary








Summary








Summary








Summary








Thank you for watching!


Technology

Object Oriented Design Principle