Object Oriented Design

Lecture 4a

OO Design 1
 Object Orientation
 Traditional procedural systems separate
data and procedures, and model these
separately
 Object orientation –views data and
functions together; data abstraction is the
basis
 The purpose of OO design is to define the
classes in the system to be built and their
relationships
 A class is a blue print for an object.
OO Design 2
 OOA and OOD
 OO techniques can be used in analysis
(requirements) as well as design
 The methods and notations are similar
 In Object Oriented Analysis (OOA) we model the
problem, while in Object Oriented Deisgn (OOD)
we model the solution
 Often OOA structures are subsumed in the
solution domain structures
 The line between OOA and OOD is not fixed

OO Design 3
OOA and OOD…

OO Design 4
 OO Concepts
 Encapsulation – grouping of related ideas
into one unit which we can refer to by a
single name
 Eg. procedures, functions, packages
 In OO, object is the unit; encapsulates
state and provides interface to access and
modify
 Object is an instance of a class

OO Design 5
 OO Concepts..
 Information hiding – use encapsulation to
restrict external visibility
 OO encapsulates the data, provides limited
access, visibility
 Information hiding can be provided without
OO – is an old concept

OO Design 6
 OO Concepts…
 State retention – functions, procedures do
not retain state; an object is aware of its
past and maintains state
 Identity – each object can be identified and
treated as a distinct entity
 Behavior – state and services together
define the behavior of an object, or how an
object responds

OO Design 7
 OO Concepts..
 Messages – through which a sender object
conveys to a target object a request
 For requesting O1
 must have – a handle for O2
 name of the operation
 information on operations that O2 requires
 General format O2.method(args)

OO Design 8
 OO Concepts..
 Classes – a class is a stencil from which objects
are created; defines the structure and services. A
class has
 An interface which defines which parts of an object can
be accessed from outside
 Body that implements the operations
 Instance variables to hold object state
 A class defines the attributes and operations
 Objects and classes are different; class is a type,
object is an instance
 State and identity is of objects
OO Design 9
 OO Concepts – access
 Operations in a class can be
 Public: accessible from outside
 Private: accessible only from within the class
 Protected: accessible from within the class and
from within subclasses
 There are some constructor and destructor
operations
 Used to modify attributes

OO Design 10
 Inheritance
 Inheritance is unique to OO
 not there in function-oriented languages/models
 Inheritance by class B from class A is the facility
by which B implicitly gets the attributes and
operations of A as part of itself
 Attributes and methods of A are reused by B
 When B inherits from A, B is the subclass or
derived class and A is the base class or superclass

OO Design 11
 Inheritance..
 A subclass B generally has a derived part
(inherited from A) and an incremental part
(is new)
 Hence, B needs to define only the
incremental part
 Creates an “is-a” relationship
 objects of type B are also objects of type A

OO Design 12
Inheritance…

OO Design 13
 Inheritance…
 The inheritance relationship between classes
forms a class hierarchy
 In models, hierarchy should represent the natural
relationships present in the problem domain
 In a hierarchy, all the common features can be
accumulated in a superclass
 An existing class can be a specialization of an
existing general class – is also called
generalization-specialization relationships

OO Design 14
Hierarchy Class Example

Attributes
Subclass has access to these

Operations
Subclass has access to these

OO Design 15
 Inheritance…Types
 Single inheritance – a subclass inherits
from only one superclass
 Class hierarchy is a tree
 Multiple inheritance – a class inherits from
more than one class
 Can cause runtime conflicts
 Repeated inheritance - a class inherits from a
class but from two separate paths

OO Design 16
 Single inheritance enables a derived
class to inherit properties and behavior
from a single parent class. It allows a
derived class to inherit the properties and
behavior of a base class, thus enabling
code reusability as well as adding new
features to the existing code.

OO Design 17
Single vs Multiple

OO Design 18
 Inheritance…
 Strict inheritance – a subclass takes all
features of parent class
 Only adds features to specialize it
 Non-strict: when some of the features have
been redefined
 Strict inheritance supports “is-a” cleanly
and has fewer side effects

OO Design 19
 Inheritance and Polymorphism
 Inheritance brings polymorphism, i.e. an object
can be of different types
 An object of type B is also an object of type A
 Hence an object has a static type and a dynamic
type
 Implications on type checking
 Also brings dynamic binding of operations which allows
writing of general code where operations do different
things depending on the type

OO Design 20
 Module Level Concepts
 Basic modules are classes
 During design key activity is to specify the
classes in the system being built
 Correctness of design is fundamental
 But design should also be “good” –
efficient, modifiable, stable, …
 Can evaluate a design using coupling,
cohesion, and open-closed principle

OO Design 21
 Coupling
 Coupling is an inter-module concept,
captures the strength of interconnection
between modules
 More tightly coupled the modules, the more
they depend on each other, more difficult
to modify one
 Low coupling is desirable for making
systems understandable and modifiable
 In OO, three types of coupling exists –
 interaction,
 component, and
 inheritance OO Design 22
 Coupling…
 Interaction coupling occurs due to methods
of a class invoking methods of other classes
 Like calling of functions
 Worst form if methods directly access internal
parts of other methods
 Still bad if methods directly manipulate
variables of other classes
 Passing information through temporary
variables is also bad

OO Design 23
 Coupling…
 Least interaction coupling if methods
communicate directly with parameters
 With least number of parameters
 With least amount of information being passed
 With only data being passed
 i.e. methods should pass the least amount
of data, with least number of parameters

OO Design 24
 Coupling…
 Component coupling – when a class A has
variables of another class C
 A has instance variables of C
 A has some parameters of type C
 A has a method with a local variable of type C
 When A is coupled with C, it is coupled with
all subclasses of C as well
 Component coupling will generally imply
the presence of interaction coupling also

OO Design 25
 Coupling…
 Inheritance coupling – two classes are
coupled if one is a subclass of the other
 Worst form – when subclass modifies a
signature of a method or deletes a method
 Coupling is bad even when same signature
but a changed implementation
 Least, when subclass only adds instance
variables and methods but does not modify
any

OO Design 26
 Cohesion
 Cohesion is an intra-module concept
 Focuses on why elements are together
 Only elements tightly related should exist together in a module
 This gives a module clear abstraction and makes it easier to
understand
 Higher cohesion leads to lower coupling – many
interacting elements are in the module
 Goal is to have higher cohesion in modules
 Three types of cohesion in OO –
 method,
 class, and
 inheritance
OO Design 27
 Cohesion…
 Method cohesion – why different code
elements are together in a method (like
cohesion in functional modules)
 Highest form is if each method implements a
clearly defined function with all elements
contributing to implementing this function
 Should be able to state what the module does
by a simple statement

OO Design 28
 Cohesion…
 Class cohesion – why different attributes
and methods are together in a class
 A class should represent a single concept with
all elements contributing towards it
 Whenever multiple concepts encapsulated,
cohesion is not as high
 A symptom of multiple concepts – different
groups of methods accessing different subsets
of attributes

OO Design 29
 Cohesion…
 Inheritance cohesion – focuses on why
classes are together in a hierarchy
 Two reasons for subclassing
 generalization-specialization
 reuse

 Cohesion is higher if the hierarchy is for

OO Design 30
 Open-closed Principle
 Principle: Classes should be open for
extension but closed for modification
 Behavior can be extended to accommodate
new requirements, but existing code is not
modified
 i.e. allows addition of code, but not modification of
existing code
 Minimizes risk of having existing functionality
stop working due to changes – a very
important consideration while changing code
 Good for programmers as they like writing new
code
OO Design 31
 Open-closed Principle…
 In OO this principle is satisfied by using
inheritance and polymorphism
 Inheritance allows creating a new class to
extend behavior without changing the
original class
 This can be used to support the open-
closed principle
 Consider example of a client object which
interacts with a printer object for printing

OO Design 32
Example

OO Design 33
 Example..
 Client directly calls methods on Printer1
 If another printer is to be allowed
 A new class Printer2 will be created
 But the client will have to be changed if it wants
to use Printer 2
 Alternative approach
 Have Printer1 a subclass of a general Printer
 For modification, add another subclass Printer 2
 Client does not need to be changed
OO Design 34
Example…

OO Design 35
 Liskov’s Substitution Principle
 Principle: Program using object O1 of base
class (superclass) C should remain
unchanged if O1 is replaced by an object of
a subclass of C
 If hierarchies follow this principle, the
open-closed principle gets supported

OO Design 36
END

OO Design 37