object oriented design principle
Post on 08-May-2015
756 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
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 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).
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 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).
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 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).
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 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).
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 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).
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 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.
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 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.
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 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.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 8/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
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
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
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
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
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
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
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
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
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
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
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 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.
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 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.
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 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.
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 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.
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 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.
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 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.
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.
“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.
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 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.
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 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.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 17/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 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
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
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 addingnew 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
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
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 20/33
Open-Closed Principle
Abstraction is the Key
What are the characteristics of the best inheritancehierarchies?
Liskov’s Substitution Principle
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 inheritancehierarchies?
Liskov’s Substitution Principle
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 inheritancehierarchies?
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)
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.
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 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.
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 thatfor all programs P defined in terms of T,
the behavior of P is unchangedwhen 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
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.
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 Tsuch that
for all programs P defined in terms of T,
the behavior of P is unchangedwhen 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
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.
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 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.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 22/33
Liskov’s Substitution Principle
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.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 23/33
Liskov’s Substitution Principle
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.
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.
We can always writeBaseClass 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
Derived classes should be substitutable for base classes.
We can always writeBaseClass 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
Derived classes should be substitutable for base classes.
We can always writeBaseClass 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 );
}
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 );
}
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 );
}
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 );
}
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);
}
}
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
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 derivedclass.
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
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))
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 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.
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 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.
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 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.
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 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.
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 levelmodules. Both should be depend upon abstractions.
Abstractions should not depend upon details. Details shoulddepend 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 levelmodules. Both should be depend upon abstractions.
Abstractions should not depend upon details. Details shoulddepend upon abstractions.
Dinh Hoang Long, Mental Log Object Oriented Design Principles, Class Design Principles 29/33
Dependency Inversion Principle
Figure 5: The Copy Program
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.
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
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
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 andmake 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
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 andmake 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
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 andmake 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
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 andmake 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
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 andmake 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
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 andmake 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
top related