Object-Oriented Design Lecture 12: Object-Oriented Principles - - PowerPoint PPT Presentation

Department of Computer Engineering

Object-Oriented Design

Lecture 12: Object-Oriented Principles

Sharif University of Technology 1

Open Closed Principle (OCP)

• Classes should be open for extension but closed for modification.
• OCP states that we should be able to add new features to our system

without having to modify our set of preexisting classes.

• One of the tenets of OCP is to reduce the coupling between classes

to the abstract level.

• Instead of creating relationships between two concrete classes, we create

relationships between a concrete class and an abstract class or an interface.

Sharif University of Technology 2

Open Closed Principle (OCP) Example

Sharif University of Technology 3

Open Closed Principle (OCP) Solution

Sharif University of Technology 4

Liskov Substitution Principle (LSP)

• Subclasses should be substitutable for their base classes.
• Also called the substitutability principle.

Sharif University of Technology 5

Dependency Inversion Principle (DIP)

• Depend upon abstractions. Do not depend upon concretions.
• The Dependency Inversion Principle (DIP) formalizes the concept of

abstract coupling and clearly states that we should couple at the abstract level, not at the concrete level.

• DIP tells us how we can adhere to OCP.

Sharif University of Technology 6

Dependency Inversion Principle (DIP)

Sharif University of Technology 7

Dependency Inversion Principle (DIP)

• let's assume the Manager class is quite complex, containing very

complex logic.

• Now we have to change it in order to introduce the new

SuperWorker

• Solution:
• Manager class doesn't require changes when adding SuperWorkers.
• Minimized risk to affect old functionality present in Manager class since we

don't change it.

• No need to redo the unit testing for Manager class.

Sharif University of Technology 8

Dependency Inversion Principle (DIP)

Sharif University of Technology 9

Interface Segregation Principle (ISP)

• Many specific interfaces are better than a single, general

interface.

• Any interface we define should be highly cohesive.

Sharif University of Technology 10

Composite Reuse Principle (CRP)

• Favor polymorphic composition of objects over inheritance.
• One of the most catastrophic mistakes that contribute to the

demise of an object-oriented system is to use inheritance as the primary reuse mechanism.

• Delegation can be a better alternative to Inheritance.

Sharif University of Technology 11

Composite Reuse Principle (CRP)

• Delegation can be seen as a reuse mechanism at the object level, while

inheritance is a reuse mechanism at the class level.

• suppose an Employee class has a method for computing the employee's annual

bonus:

class Employee { Money computeBonus() { /* skimpy default bonus */ } // etc.}

• Different subclasses of Employee: Manager, Programmer, Secretary, etc.
• may want to override this method to reflect the fact that some types of

employees (managers) get more generous bonuses than others (secretaries and programmers):

class Manager extends Employee { Money computeBonus() { /* gerenous bonus */ } // etc.}

• There are several problems with this solution.

Sharif University of Technology 12

Composite Reuse Principle (CRP)

• All programmers get the same bonus. What if we wanted to vary the bonus

computation among programmers?

• Would we need to introduce a special subclass of Programmer?

class SeniorProgrammer extends Programmer { Money computeBonus() { /* gerenous bonus */ } // etc.}

• Note also that this leads to code duplication.
• What if we wanted to change the bonus computation for a particular employee?
• For example, what if we wanted to promote Smith from programmer to senior programmer?

Would this require us to recompile any code?

• What if we decided to give all programmers the same generous bonus that

managers get? What changes would we need to make?

• Should "generous bonus" become the new default algorithm that is overridden in the Secretary

class with the skimpy bonus algorithm?

• Should we copy and paste the "generous bonus" algorithm from manager to Programmer?

Sharif University of Technology 13

Composite Reuse Principle (CRP)

• Now different employees can have different bonus calculators, regardless of the

class they instantiate.

• Even better, the bonus calculator used by a particular employee can be changed

dynamically.

Sharif University of Technology 14

Principle of Least Knowledge (PLK)

• For an operation O on a class C, only operations on the following
• bjects should be called: itself, its parameters, objects it creates, or its

contained instance objects.

• Also called the Law of Demeter.
• The basic idea is to avoid calling any methods on an object where

the reference to that object is obtained by calling a method on another object (Transitive Visibility).

• The primary benefit is that the calling method doesn’t need to

understand the structural makeup of the object its invoking methods upon.

Sharif University of Technology 15

Principle of Least Knowledge (PLK)

• LoD (or Principle of Least Knowledge): Each module should have only

limited knowledge about other units: only units "closely" related to the current unit

• In particular: Don’t talk to strangers!
• For instance, no a.getB().getC().foo()
• Motivated by low coupling

Sharif University of Technology 16

GRASP

• Acronym stands for General Responsibility Assignment Software

Patterns.

• A set of 9 Patterns introduced as a learning aid by Craig Larman.
• Describe fundamental principles for object-oriented design and

responsibility assignment, expressed as patterns.

• The skillful assignment of responsibilities is extremely important in
• bject design.
• Determining the assignment of responsibilities often occurs during

the creation of interaction diagrams, and certainly during programming.

Sharif University of Technology 17

GRASP: Patterns

• 1. Information Expert

2.Creator

• 3. Low Coupling

4.High Cohesion 5.Controller 6.Polymorphism

• 7. Indirection

8.Pure Fabrication 9.Protected Variations

Sharif University of Technology 18

GRASP: Information Expert

Sharif University of Technology 19

 As a general principle of assigning responsibilities to

• bjects, assign a responsibility to the information expert:

 i.e. the class that has the information necessary to fulfill the

responsibility.

GRASP: Information Expert

Sharif University of Technology 20

• Given an object o, which responsibilities can be assigned

to o?

• Expert principle says – assign those responsibilities to o

for which o has the information to fulfill that responsibility.

• They have all the information needed to perform
• perations, or in some cases they collaborate with others

to fulfill their responsibilities.

GRASP: Example for Expert

Sharif University of Technology 21

 Assume we need to get all the videos of a VideoStore.  Since VideoStore knows about all the videos, we can

assign this responsibility of giving all the videos can be assigned to VideoStore class.

 VideoStore is the information expert.

GRASP: Another Example for Expert

Sharif University of Technology 22

 Who should be responsible for knowing the grand total of a

sale?

GRASP: Creator

• Assign class B the responsibility to create an instance of class A if one
• r more of the following is true:
• B aggregates A objects.
• B contains A objects.
• B records instances of A objects.
• B closely uses A objects.
• B has the initializing data that will be passed to A when it is created (thus B is

an Expert with respect to creating A).

• B is a creator of A objects.
• If more than one option applies, prefer a class B which aggregates or

contains class A.

Sharif University of Technology 23

GRASP: Creator

• “Container” object creates “contained” objects.
• Decide who can be creator based on the objects association and

their interaction.

• Consider VideoStore and Video in that store.
• VideoStore has an aggregation association with Video. i.e,

VideoStore is the container and the Video is the contained object.

• So, we can instantiate video object in VideoStore class

Sharif University of Technology 24

GRASP: Low Coupling

• Assign a responsibility so that coupling remains low.
• A class with high (or strong) coupling relies on many other
• classes. Such classes may be undesirable; some suffer from the

following problems:

• Changes in related classes force local changes.
• Harder to understand in isolation.
• Harder to reuse because its use requires the additional presence of the

classes on which it is dependent.

Sharif University of Technology 25

GRASP: Low Coupling

• Two elements are coupled, if
• One element has aggregation/composition association with

another element.

• One element implements/extends other element.

Sharif University of Technology 26

GRASP: Low Coupling

Sharif University of Technology 27

GRASP: High Cohesion

• Assign a responsibility so that cohesion remains high.
• A class with low cohesion does many unrelated things, or does

too much work.

• Such classes are undesirable; they suffer from the following

problems:

• hard to comprehend
• hard to reuse
• hard to maintain
• Delicate: constantly affected by change

Sharif University of Technology 28

GRASP: High Cohesion

Sharif University of Technology 29

GRASP: Controller

• Assign the responsibility for receiving or handling a system event message to a

class representing one of the following choices:

• Represents the overall system, device, or subsystem (facade controller).
• Represents a use case scenario within which the system event occurs (a use-

case- or session-controller).

• Use the same controller class for all system events in the same use case

scenario.

• Informally, a session is an instance of a conversation with an actor.
• Note that "window," "applet," "widget," "view," and "document" classes are not on

this list.

• Such classes should not fulfill the tasks associated with system events, they

typically delegate these events to a controller.

Sharif University of Technology 30

GRASP: Controller

• Deals with how to delegate the request from the UI layer objects to domain layer
• bjects.
• This object is called controller object which receives request from UI layer object

and then controls/coordinates with other object of the domain layer to fulfill the request.

• It delegates the work to other class and coordinates the overall activity

Sharif University of Technology 31

GRASP: Polymorphism

• When related alternatives or behaviors vary by type (class), assign

responsibility for the behavior — using polymorphic operations — to the types for which the behavior varies.

• Define the behavior in a common base class or, preferably, in an

interface.

Sharif University of Technology 32

GRASP: Indirection

• Assign the responsibility to an intermediate object to mediate

between other components or services so that they are not directly coupled.

• The intermediary creates an indirection between the other

components.

• Beware of transitive visibility.

Sharif University of Technology 33

GRASP: Indirection

• Here polymorphism illustrates indirection
• Class Employee provides a level of indirection to other units of the

system.

Sharif University of Technology 34

GRASP: Pure Fabrication

• Assign a highly cohesive set of responsibilities to an artificial or

convenience class that does not represent a problem domain concept — something made up, to support high cohesion, low coupling, and reuse.

• Example: a class that is solely responsible for saving objects in some

kind of persistent storage medium, such as a relational database; call it the PersistentStorage.

• This class is a Pure Fabrication — a figment of the imagination.

Sharif University of Technology 35

GRASP: Pure Fabrication

• Fabricated class/ artificial class – assign set of related responsibilities

that doesn't represent any domain object.

• Provides a highly cohesive set of activities.
• Examples: Adapter, Strategy
• Benefits: High cohesion, low coupling and can reuse this class.

Sharif University of Technology 36

GRASP: Pure Fabrication

• Suppose we Shape class, if we must store the shape data in a

database.

• If we put this responsibility in Shape class, there will be many

database related operations thus making Shape incohesive.

• So, create a fabricated class DBStore which is responsible to perform

all database operations.

• Similarly logInterface which is responsible for logging information is

also a good example for Pure Fabrication.

Sharif University of Technology 37

GRASP: Protected Variations

• Identify points of predicted variation or instability; assign

responsibilities to create a stable interface around them.

• Note: The term "interface" is used in the broadest sense of an access

view; it does not literally only mean something like a Java or COM interface.

Sharif University of Technology 38

Design by Contract (DBC)

• A discipline of analysis, design, implementation, and management.
• Bertrand Meyer introduced Design by Contract in Eiffel as a

powerful technique for producing reliable software.

• Its key elements are assertions: boolean expressions that define

correct program states at arbitrary locations in the code.

Sharif University of Technology 39

Design by Contract (DBC): Assertions

• Simple assertions belong to individual statements in a program, yet

important DBC assertions are defined on classes:

• Per- method assertions:
• Precondition: A condition that must be true of the parameters of a method

and/or data members – if the method is to behave correctly – PRIOR to running the code in the method.

• Postcondition: A condition that is true AFTER running the code in a method.
• Per-class assertions:
• Class Invariant: A condition that is true BEFORE and AFTER running the code in

a method (except constructors and destructors).

Sharif University of Technology 40

Design by Contract (DBC): Contract

• Assertions in a class specify a contract between its instances and

their clients.

• According to the contract a server promises to return results

satisfying the postconditions if a client requests available services and provides input data satisfying the preconditions.

• Invariants must be satisfied before and after each service.
• Neither party to the contract (the clients/consumers and

servers/suppliers) shall be allowed to rely on something else than that which is explicitly stated in the contract.

Sharif University of Technology 41

Design by Contract (DBC): Inheritance

• The class invariants of all ancestors must also be obeyed by all

children; they can also be strengthened.

• Inherited preconditions may only be weakened. This means a new

implementation may never restrict the circumstances under which a client call is valid beyond what has been specified by the ancestor.

• It may, however, relax the rules and also accept calls that would have been

rejected by the ancestor.

• Inherited postconditions may only be strengthened. This means a

new implementation must fulfil what the ancestors have undertaken to do, but may deliver more.

• "Children should not provide less or expect more than their

ancestors."

Sharif University of Technology 42

Reference

• Larman, C., Applying UML and Patterns: An Introduction to Object-

Oriented Analysis and Design and Iterative Development, 3rd Ed. Prentice-Hall, 2004.

Sharif University of Technology 43