Object-Oriented

Design Principles

The Pillars of the

Paradigm
Abstraction

Encapsulation

Hierarchy

Association, Aggregation

Inheritance

Polymorphism

OOP- 2
 What’s OO?

Is it using Objects?

Is it using C++, Java, C#, Smalltalk?

No, its got to be using UML?! :)

What makes a program OO?

How do you measure good design?

OOP- 3

Measuring Quality
of an Abstraction

Designing Classes & Objects

An incremental, iterative process

Difficult to design right the first time

OOP- 4
 Metrics for class design
Coupling

inheritance Vs. coupling

Strong coupling complicates a system

design for weakest possible coupling

Cohesion

degree of connectivity among the elements of a single

module/class

coincidental cohesion: all elements related undesirable

Functional cohesion: work together to provide well-

bounded behavior
OOP- 5

Law of Demeter
“Methods of a class should not depend in any
way on the structure of any class, except the
immediate structure of their own class.
Further, each method should send messages to
objects belonging to a very limited set of
classes only.”

First part talks about encapsulation and cohesion

Second part talks about low coupling
OOP- 6
 Tell Don’t Ask

“Procedural code gets information and then

makes decisions. OO code tells objects to do
things,” Alec Sharp in Smalltalk by Example.

Objects should take limited responsibility and

rely on others to provide appropriate service

Command-Query Separation: categorize

methods as command or query

OOP- 7

David Bock’s Example

on LoD/TDA
David Bocks’ The Paper Boy, The Wallet, and The Law Of Demeter

Failing LoD
=> drives away shiny new
PaperBoy’s method does: Jaguar!
customer.waller.totalMoney;

Honoring LoD => Customer controls

amount, where it’s kept
PaperBoy’s method does: (wallet, hidden in cookie
customer.getPayment(...); jar,...)

OOP- 8
 Train Wreck Coding
You may find code that continues to call on objects
returned by methods in sequence

customer.getAddress().getCity().getCounty()...

This indicates that you are interested in working

with objects that are farther away than those that are
your close friends

Hard to understand

Hard to debug

Lacks Cohesion

Good candidate for refactoring

OOP- 9

Bad design
Perils of a bad design

Rigidity–Hard to change, results in cascade of changes

Fragility–Breaks easily and often

Immobility–Hard to reuse (due to coupling)

Viscosity–Easy to do wrong things, hard to do right things

Needless Complexity–Complicated class design, overly

generalized

Needless Repetition–Copy and Paste away

Opacity –Hard to understand

OOP- 10
 Principles
Guiding Principles that help develop better
systems

Use principles only where they apply

You must see the symptoms to apply them

If you apply arbitrarily, the code ends up with

Needless Complexity
OOP- 11

YAGNI
You Aren’t Going To Need It

You are looking out for extensibility

You are not sure if a certain functionality is

needed

Designing what you do not know fully leads to

unnecessary complexity and heavy weight
design

If you really need it, design it at that time

OOP- 12
 DRY
Don’t Repeat Yourself

“Every Piece of Knowledge must have a single,

unambiguous, authoritative representation within a system”

One of the most difficult, but most seen

How many times have you see this happen

Application where
Execution UI did business
Engine Font end
validation.
Start out due to flaw in
(chokes on Application Engine.
Once flaw was rectified,
certain took us weeks to fix
names of the UI due to duplication
of validation logic.
objects) OOP- 13

DRY
Some times hard to realize this

It is much easier to copy, paste and modify

code to get it working the way you want it,
isn’t it

Duplicating code results in

Poor maintainability

Expensive to fix bugs/errors

Hard to keep up with change

OOP- 14
 SRP
Single-Responsibility Principle

What metric comes to mind?

“A class should have only one reason to

change”

Some C++ books promoted bad design

Overloading input/output operators!

What if you do not want to display on a

terminal any more?

GUI based, or web based?

OOP- 15

SRP…
Alarm
Control
UI +alert()
System
+display(Panel)

Faces more frequent change

Has greater dependency (to UI related stuff)

Related topics:
MVC Alarm
Analysis model stereotypes : Control
+alert() System
Control Entity Boundary

AlarmUI
UI +display(Panel)

OOP- 16
 SRP at Module Level
Can be extended to module level as well

Component
GUI Framework GUI Framework
V 1.0 Development V 1.1
Utilities
Throw it in there

GUI Framework
Forced to accept V 1.2
Irrelevant change
User

OOP- 17

SRP affects Reuse

Lower cohesion results in poor reuse

My brother just bought a new DVD and a

big screen TV!

He offers to give me his VCR!

I have a great TV and all I need is a VCR

Here is what I found when I went to pickup!

Disclaimer: This slide not Tight coupling

intended to say anything
about the brand of product Poor Cohesion
shown here as an example!
Bad for reuse
OOP- 18
 Nature of code
“Software Systems change during their life
time”

Both better designs and poor designs have to

face the changes; good designs are stable

OOP- 19

OCP…

Bertrand Meyer:

“Software Entities (Classes, Modules,

Functions, etc.) should be open for extension,
but closed for modification”

OOP- 20
 OCP…
Characteristics of a poor design:

Single change results in cascade of changes

Program is fragile, rigid and unpredictable

Characteristics of good design:

Modules never change

Extend Module’s behavior by adding new

code, not changing existing code

OOP- 21

OCP…
Software Modules must

be open for extension

module’s behavior can be extended

closed for modification

source code for the module must not be

changed

OOP- 22
 OCP…
Piston
Car
Engine

How to make the Car run efficiently with Turbo Engine ?

Only by changing Car in the above design

OOP- 23

OCP…
Abstract
Car
Engine

Piston
Engine
A class must not
Abstraction & Polymorphism depend on a
are the Key Concrete class; it
must depend on an
abstract class OOP- 24
 OCP…
Strategic Closure:

No program can be 100% closed

There will always be changes against which

the module is not closed

Closure is not complete - it is strategic

Designer must decide what kinds of changes to

close the design for.

This is where the experience and problem

domain knowledge of the designer comes in
OOP- 25

OCP…
Heuristics and Conventions that arise from OCP

Make all member variables private

encapsulation: All classes/code that depend on

my class are closed from change to the variable
names or their implementation within my class.
Member functions of my class are never closed
from these changes

Further, if this were public, no class will be

closed against improper changes made
by any other class

No global variables OOP- 26

 OCP…
Heuristics and Conventions that arise from
OCP...

RTTI is ugly and dangerous

If a module tries to dynamically cast a base

class pointer to several derived classes, any
time you extend the inheritance hierarchy,
you need to change the module

Not all these situations violate OCP

all the time

OOP- 27

Liskov Substitution
Principle
Inheritance is used to realize Abstraction

! and Polymorphism which are key to OCP

How do we measure the quality of inheritance?

LSP:

! “Functions that use pointers or references to

base classes must be

! able to use objects of derived classes without

knowing it”
OOP- 28
 Inheritance
A

public/is-a

B
!B publicly inherits from (“is-a”) A means
!Every object of type B is also object of type A
!What’s true of object of A is also of object of B
!A represents a more general concept than B
!B represents more specialized concept than A
!anywhere an object of A can be used, an object of B can be used
OOP- 29

Behavior
Advertised Behavior of an object

Advertised Requirements (Pre-Condition)

Advertised Promise (Post Condition)

Stack and eStack example

OOP- 30
Design by Contract
Design by Contract

Advertised Behavior of the

Derived class is Substitutable for that of the

Base class

Substitutability: Derived class Services Require

no more and promise no less than the
specifications of the corresponding services in
the base class

OOP- 31

LSP

“Any Derived class object must be

substitutable where ever a Base class object is
used, without the need for the user to know
the difference”

OOP- 32
 LSP in Java?
LSP is being used in Java at least in two places

Overriding methods can not throw new

unrelated exceptions

Overriding method’s access can’t be more

restrictive than the overridden method

for instance you can’t override a public

method as protected or private in derived
class

OOP- 33

Nature of Bad Design

Bad Design is one that is

Rigid - hard to change since changes affect

too many parts

Fragile - unexpected parts break upon

change

Immobile - hard to separate from current

application for reuse in another

OOP- 34
 Ramifications
Depends
Controller Clock
for Alarm

Controller needs an alarm

Clock has it, so why not use it?

Concrete Controller depends on concrete Clock

Changes to Clock affect Controller

Hard to make Controller use different alarm (fails

OCP)

Clock has multiple responsibilities (fails SRP)

OOP- 35

Alternate Design
Controller IAlarm

Clock Timer

Dependency has been inverted

Both Controller and Clock depend on

Abstraction (IAlarm)

Changes to Clock does not affect Controller

Better reuse results as well

OOP- 36
 Inheritance Vs.
Delegation
Inheritance is one of the most abused concepts
in OO programming

Often, delegation may be a better choice than

inheritance

When should you use inheritance vs.

delegation?

OOP- 37

Inheritance Vs.
Delegation...

If an object of B may be used in place of an

object of A, use inheritance

If an object of B may use an object of A, then

use delegation

OOP- 38
 DIP

Dependency Inversion Principle

“High level modules should not depend upon

low level modules. Both should depend upon
abstractions.”

“Abstractions should not depend upon details.

! Details should depend upon abstractions.”

OOP- 39

The Founding
Principles
The three principles are closely related

Violating either LSP or DIP invariably results

in violating OCP

It is important to keep in mind these principles

to get the most out of OO development
OOP- 40
 Fat Interfaces
C1 A Class C2

Clients should not know this as a single class

They should know about abstract base classes with cohesive interfaces
Classes tend to grow into fat interfaces

Examples of this can been seen in several APIs

Interface of the class
Less cohesive (fails SRP) may be split
I1
C1 C2
A Class
I2
Interface does not mean “all
methods in a class”
OOP- 41

Growth of an interface
IMicrowave
C1 +cook(time) C2
+stop()
A few days later,
A few days later,
Client C1 wants it to notify MicrowaveImpl Client C2 wants it to chime
(workaholic client?!)

IMicrowave
C1 +cook(time) C2
+stop()
Clients are forced to
+chime()
use interfaces they
+notify(…)
do not care about. All implementations
May result in greater
must carry the weights
coupling, dependency MicrowaveImpl
to more libraries
OOP- 42
 ISP
Interface Segregation Principle

“Clients should not be forced to depend on

methods that they do not use”

IMicrowave
C1 C2
+cook(time)
+stop()
INotify IChimer
+notify(…) +chime()

MicrowaveImpl1 MicrowaveImpl2
OOP- 43

Reuse/Release
Equivalency Principle

“The granularity of reuse is the same as the

granularity of release. Only components that
are released through a tracking system can be
effectively reused.”

OOP- 44
 Reuse/Release
Equivalency Principle

Release

A class generally collaborates with other

classes

For a class to be reused, you need also the

classes that this class depends on

All related classes must be released together

OOP- 45

Reuse/Release
Equivalency Principle
Tracking

A class being reused must not change in an

uncontrolled manner

Code copying is a poor form of reuse

Software must be released in small chunks -

components

Each chunk must have a version number

Reusers may decide on an appropriate time to

use a newer version of a component release OOP- 46
 Common Closure Principle

“Classes within a released component should

share common closure. If one need to be
changed, they all are likely to need to be
changed. What affects one, affect all.”

OOP- 47

Common Closure Principle

A change must not cause modification to all

released components

Change must affect smallest possible number

of released components

Classes within a component must be cohesive

Given a particular kind of change, either all

classes in a component must be modified or no
class needs to be modified

Reduces frequency of re-release of component

OOP- 48
 Common Reuse Principle

“Classes within a released component should

be reused together. That is, it must be
impossible to separate the component in order
to reuse less than the total.”

OOP- 49

Common Reuse Principle...

Components must be focused

Component must not contain classes that an

user is not likely to reuse

user may be forced to accept a new release

due to changes to unused classes

Component must be narrow

OOP- 50
 Acyclic Dependence Principle

“The dependency structure for released

component must be a Directed Acyclic Graph.
There can be no cycles.”

OOP- 51

Acyclic Dependence Principle

If there are cycles, it becomes hard to maintain

Change ripples through

Can’t release components in small increments

OOP- 52
 Stable Dependency Principle

“Dependencies between released components

must run in the direction of stability. The
dependee must be more stable than the
depender.”

OOP- 53

Stable Dependency
Principle
A component can never be more stable than the one
it depends upon

Instability I = Ce / (Ca + Ce),

where

Ca - # of classes outside that depend upon this

class

Ce - # of classes outside that this class depends

upon

0"I"1

0 - ultimately stable; 1 - ultimately unstable OOP- 54

 Stable Dependency
Principle...

Components should be arranged such that

components with a high I metrics should
depend upon component with low I metrics

OOP- 55

Stable Abstraction
Principle

“The more stable a component is, the more it

must consist of abstract classes. A completely
stable category should consist of nothing but
abstract classes.”

OOP- 56
 Stable Abstraction
Principle

Implementation of methods change more often

than the interface

Interfaces have more intrinsic stability than

executable code

Abstraction of a Component

! A = (# of abstract classes) / (# of classes)

0"A"1

0 - no abstract classes; 1 - all abstract classes

OOP- 57

Stability Vs.
Abstractness
A
(0, 1)
Th (1,1)
Highly
eM
Abstractness

instable &
ain abstract
Maximally
Se (Rigid)
stable qu
& abstract en
ce
(1, 0)
0 Instability
Highly
I
Maximally
stable &
instable
Concrete
& concrete
(Rigid) OOP- 58
 Distance from the
main sequence
D = |(A + I - 1) / #2 |

0 " D " 0.707; Desirable value of D is closed to 0

Normalized form D' = |(A + I -1)|

Calculate D value for each component

Component whose D value is not near Zero can be

reexamined and restructured
OOP- 59

Applying the Principles

Developing with OO is more than

Using a certain language

Creating objects

Drawing UML

It tends to elude even experienced developers

Following the principles while developing code helps

attain agility

Use of each principle should be justified at each

occurrence, however OOP- 60
 OO Principles and
Agile Development
These principles are more relevant during
iterative development and refactoring than
upfront design

As the requirements become clearer and we

understand the specifics the forces behind the
use of these principle become clear as well

OOP- 61