Gang of Four

DESIGN PATTERNS – LEVEL-0

1 A Presentation by

Raghavaraju Kudari
SOFTWARE COMPLEXITY
 Most of the objects in the world exhibit great complexity e.g.
photosynthesis process, heart beating etc.
 In the same way, Software is also complex, especially industry
strength software , such as air traffic controller, database
systems that maintain the integrity
 Such complexity if too great for one person to comprehend
and this complexity can never be eliminated, although it can be
tamed.

2
WHY SOFTWARE IS COMPLEX?
 GradyBooch derives four elements that are responsible for
the complexity of software.
I. Complexity of the Problem Domain
 Unavoidable Domain Complexity
 Impedance mismatch between Users & Developers

 Changing nature of requirements.

II. Difficulty in managing the developmental process

 Big teams
III. Flexibility possible through software.
IV. Problems of characterizing the behavior of discrete systems
3
COMPLEXITY

Software Developers strive to create an illusion of

simplicity

4
HOW TO RESOLVE COMPLEXITY?

In Software Development the complexity can

be resolved in two ways
I. Algorithmic Decomposition
 It is Concerned with the decomposition of problem into
algorithms

II. Object Oriented Decomposition

 In this , we identify players or objects that are part of the
system. These objects collaborate with each other to give rise to
the functionality of the system.
5
PROCEDURAL VS. OBJECT-ORIENTED

 Procedural  Object Oriented

Withdraw, deposit, transfer Customer, money, account

 ADVANTAGES OF OO DECOMPOSITION

 Object Oriented Decomposition helps in organizing

the inherent complexity software systems.
 It yields smaller systems through reuse of common
functionality.
 OO systems are more flexible to change and are thus
able to evolve over a period of time.
 In OO systems, the decomposition is eased by factors
such as abstraction & hierarchy. Both are natural
outcomes of humans when presented with a problem.
7
 OBJECT ORIENTED LANGUAGES

 Object Oriented Languages evolved to help the

developers to exploit the power of object oriented
programming.
 This led to concept called as Object Model that
contain the following important pillars.
 Abstraction
 Encapsulation
 Hierarchy
 Modularity
 Polymorphism 8
ABSTRACTION

Abstraction focuses upon the essential characteristics of

some object ,relative to the perspective of the viewer.

9
ABSTRACTION EXAMPLE

 Whatdo you gather from the following examples of Air

Conditioner interfaces
interface AC{ enum Speed{low,medium,high};
public void switchOn();
public void compress();
public void dissipateHeat(); interface AC{
public void setFanRPM(int public void switchOn();
rpm); public void setFanSpeed(Speed
public void moveFins(float s);
angle); public void setTemparature();
public void sensRoomTemp(); }
}

10
ENCAPSULATION
 Encapsulation hides the internal details of an object.

11
MODULARITY
 Modularity packages abstractions into discrete units which are
developed independently.

12
HIERARCHY
 In “is a” relationship, a subclass will inherit the structure and
behavior of its super class.

13
HIERARCHY: “IS A” RELATIONSHIP

14
HIERARCHY
 Abstractions form a hierarchy.
In this example the toy mice
are composed of other objects
and signifies “part of ”
relationship.

15
HIERARCHY: “HAS A” RELATIONSHIP

16
POLYMORPHISM EXAMPLE
 All movable objects can Move
 All objects that Move can be represented by the super class
“MovableObject”
 The exact object represented need not be known.It will
respond automatically to the Move command, and in its own
way.

18
POLYMORPHISM
 OO languages represent Polymorphism in two ways.
1. Compile time Polymorphism or Parametric
Polymorphism
Means that types will be resolved at compile
time.
Example is overloading

2. Dynamic Polymorphism or Runtime

Polymorphism.
Means that types will be resolved at runtime.

This is possible through overriding. 19

 OO PARADIGM
 Object Oriented Paradigm was considered as a panacea for
software industry.
 But realization soon dawned that the promises OOP made were
half baked.
 Hierarchy promises reuse and extensibility
 Encapsulation promises safety of data.
 Designers began to face problems while designing the software
using OO paradigm.
 Good designers solved the problems and documented them, so
that the same problems in future can be solved readily.
 This gave birth to design patterns- generic solutions to
common problems encountered in object oriented software
20
design.
 PRINCIPLES OF OBJECT ORIENTED DESIGN

 The Design Patterns are themselves built on the

principles of good Object Oriented Design.
 Following are the some of the principles that can be
followed while designing an object oriented system.

 Single Responsibility Principle

 The Open Closed Principle
 The Liskov Substitution Principle
 The dependency inversion Principle
21
 The interface Segregation Principle
 CASE STUDY

 Consider a class representing Employees of an

organization.
 Every Employee has a basic salary, and total salary is
calculated on some criteria.
 The Employee objects are serialized in a file.

22
CASE STUDY

23
CASE STUDY

24
 CASE STUDY

 It has been decided to also save the Employee

information to the database.
 Consequently , the developers have added some more
code in the class.
 Will this change cause any problem

25
CASE STUDY

26
 THE SINGLE RESPONSIBILITY PRINCIPLE
 There should never be more than one reason for a class to
change
 Responsibility is defined as “a reason for change”. If a class
have more than one reason to change, then the class has more
than one responsibility.
 It is important to separate the responsibilities in separate
classes, so that the change in one does not manifest itself into
other.
 If a class has more than one responsibility, then the
responsibilities become coupled. This leads to a fragile design.
 Therefore if a class has more than one responsibility that can
change in future, separate it and encapsulate it (in another
class). 27
CASE STUDY

A banking application has a class as shown for

representing different types of accounts
 Can you spot design problems with the displayed
class.

28
CASE STUDY

29
 SOLUTION

 You should always anticipate future changes while

designing.
 This will translate into gains later, when you have to
add more features or extend existing code.
 The changes can be incorporated without disturbing
the existing code, thus saving endless hours of
testing, bug finding , compilation, dependency checks
etc.

30
 THE OPEN CLOSED PRINCIPLE
 A module should be open for extension, but closed for modification
 This
is most important design principle.
 Modules implementing OCP have two attributes.
 They are open for extension and their behavior can be changed
through extension. In other words , we can change what the module
does through extension.
 They are closed for modification. Extending the behavior of the
module does not result in a change to the source or binary of the
module.
 The question that comes up is how to change the behavior of
a module without modifying it? The answer is to create
abstraction that represents a group of possible behaviors.
 Through polymorphism, the client can use any of the
subclasses of the abstraction without depending directly on 31
them.
 THE OPEN CLOSED PRINCIPLE

 In many ways, The Open Closed Principle is at the

heart of object oriented design.
 Embracing this principle gives greatest benefits of
object oriented technology; flexibility, reusability and
maintainability.
 But it is also not a good idea to apply this principle
to every part of the application.
 The decision has to made by the developers to apply
abstractions to only those parts which exhibit
frequent changes. 32
 THE LISKOV SUBSTITUTION PRINCIPLE
 Functions that use references to base classes must be able
to use objects of derived classes without knowing it
 This principle was devised by Barbara Liskov in her work
regarding data abstraction.
 The concept means that a user of a base class should
continue to function properly if a derivative of that base
class is passed to it.
 If a function uses base reference and knows about all the
derivatives, then it violates the OCP because it must be
modified whenever a new derivate of the base class is
33
created.
 EXAMPLE

 Suppose you have hierarchy of widgets as follows. All

the widgets implement common operations defined
in the base Widget

34
EXAMPLE

35
EXAMPLE

36
 CONCLUSION
 The Open-Closed Principle is at the heart of object
oriented design. Liskov Substitution Principle is an
important feature of all programs that conform to
Open - Closed Principle.
 It is only when derived types are completely
substitutable for their base types that functions that
use those base types can be reused without problems.
 This means existing code will work without any
changes with the future subclasses.
 It enables us to change the derived types without
effecting the other parts of the application. 37
 DEPENDENCY INVERSION PRINCIPLE
 Program to an interface, not an implementation
 The powerful interpretation of DIP is simple:
"Depend upon abstractions". This means that you
should not depend on a concrete class.
 No variable should hold a reference to a concrete
class
 No class should derive from a concrete class
 DIP states the primary mechanism, if OCP states the
goal of OO architecture.
 Abstractionsserve as "hinge points" where the design
can be bent or extended without themselves being 38
modified.
DEPENDENCY INVERSION PRINCIPLE
 Consider an application that regulates the
temperature of a furnace.
 The regulator reads the temperature from the
thermometer & regulates the temperature of the
furnace

39
 CASE STUDY
 The high level modules contain the important policy
decisions and business models of an application and
represent the identity of the application.
 In such high level modules depend on low level
modules, then any change to the low level modules
will cause the high level modules to change.
 This dependency needs to be inverted so that the low
level modules are dependent on the high level
modules.

40
 APPLYING DIP
 This is how the application
looks after applying DIP.
 Regulator can now be used
with any kind of sensor &
heater.
 The low level modules
(Thermometer, Furnace) are
now dependent on high level
module (Regulator)
 The dependency has been
inverted 41
 CASE STUDY
A programmer is creating a library
for I/O
 Depending on the requirement, the
clients can use either TextFile or the
StreamFile
 The design follows OCP,LSP &
DIP
 Clients use the classes through an
interface
 A function taking IFile reference will
still work if passed a TextFile or
StramFile object
 More classes can be added without 42

breaking the code

CASE STUDY
 The programmer now wants to add support for
sockets and pipes
 He creates two classes called as Socket & Pipe and
inherits them from IFile interface
 But what would the implementation of seek(), tell()
& size() be for these classes? These functions are
useless for sockets and pipes.
 One solution is implement the functions and throw a
“NotSupportedException” if these are called from
the client code
43
CASE STUDY

44
 CASE STUDY
 The following function will work fine as long as a TextFile or
StreamFile objects are passed to it.
 But it would fail if a Socket or Pipe object is passed to it
because it will throw Exception. So its violates LSP.
 The client is not wrong in assuming the correctness of
getSize() method for derivates of IFile, it is the IFile
interface that is violating the part of the contract.
 It contains functions which are not applicable to all of its
derived classes.
 Such interface is called as a fat interface contains methods
which are not useful to some of its clients.
45
 INTERFACE SEGREGATION PRINCIPLE
 Many client specific interfaces are better than one general
purpose interface
 Clients should not be forced to depend on methods they
do not use.
 This principal deals with the disadvantages of fat interfaces
 It suggests that interfaces can be broken up into groups of
functions and each group will serve a different set of clients.
 If ever, a client exerts a change one the interface, other clients
will be unaffected and the impact of change is minimized.

46
 APPLYING ISP
 Application of this principle leads to interfaces that are
clean, small and easily maintainable
 Such principles do not violate any of the OO Principles and
lead to a better design.

47
48