CHAPTER 7
INTRODUCTION TO
OBJECTS
Slide 7.1
Overview









What is a module?
Cohesion
Coupling
Data encapsulation product maintenance
Abstract data types
Information hiding
Objects
Inheritance, polymorphism and dynamic
binding
Cohesion and coupling of objects
Slide 7.2
Introduction to Objects

What is a module?
– A lexically contiguous sequence of program
statements, bounded by boundary elements, with an
aggregate identifier (name)
Slide 7.3
Design of Computer

A highly incompetent
computer architect
decides to build an
ALU, shifter and 16
registers with AND,
OR, and NOT gates,
rather than NAND or
NOR gates.
Slide 7.4
Design of Computer (contd)

Architect designs
3 silicon chips
Slide 7.5
Design of Computer (contd)


Redesign
with one gate
type per chip
Resulting
“masterpiece”
Slide 7.6
Computer Design (contd)

The two designs are functionally equivalent
– Second design is
»
»
»
»

Hard to understand
Hard to locate faults
Difficult to extend or enhance
Cannot be reused in another product
Modules must be like the first design
– Maximal interactions within modules, minimal
interactions between modules
Slide 7.7
Composite/Structured Design (C/SD)

Method for breaking up a product into modules for
– Maximal interaction within module, and
– Minimal interaction between modules

Module cohesion
– Degree of interaction within a module

Module coupling
– Degree of interaction between modules
High Cohesion but Low Coupling is desirable
Slide 7.8
Action, Logic, and Context of Module





The action of a module – what it does
The logic of a module – how the module
performs its action
The context of a module is the specific
usage of that module
In C/SD, the name of a module is its action
Example
– Module computes square root of double precision
integers using Newton’s algorithm. Module is
named compute square root
Slide 7.9
Cohesion


The degree of interaction within a module
Seven categories or levels of cohesion
– Functional cohesion is optimal for the structured paradigm
– Informational cohesion is optimal for OO paradigm
Slide 7.10
1. Coincidental Cohesion


A module has coincidental cohesion if it performs
multiple, completely unrelated actions
Example
– print next line, reverse string of characters comprising
second parameter, add 7 to fifth parameter, convert
fourth parameter to floating point

Arise from rules like
– “Every module will consist of between 35 and 50
statements”
Slide 7.11
Why Is Coincidental Cohesion So Bad?



Degrades maintainability
Modules are not reusable
This is easy to fix
– Break into separate modules each performing one task
Slide 7.12
2. Logical Cohesion


A module has logical cohesion when it performs
a series of related actions, one of which is
selected by the calling module
Example 1
function code = 7;
new operation (op code, dummy 1, dummy 2, dummy 3);
// dummy 1, dummy 2, and dummy 3 are dummy variables,
// not used if function code is equal to 7

Example 2
– Module performing all input and output

Example 3
– One version of OS/VS2 contained logical cohesion
module performing 13 different actions. Interface
contained 21 pieces of data
Slide 7.13
Why Is Logical Cohesion So Bad?



The interface is difficult to understand
Code for more than one action may be
intertwined, leading to maintenance problems
Difficult to reuse
Slide 7.14
Why Is Logical Cohesion So Bad? (contd)

Example: If a new tape unit is installed, what
sections of code should be modified?
Slide 7.15
3. Temporal Cohesion


A module has temporal cohesion when it
performs a series of actions related in time
Example
– open old master file, new master file, transaction file,
print file, initialize sales district table, read first
transaction record, read first old master record (a.k.a.
perform initialization)
Slide 7.16
Why Is Temporal Cohesion So Bad?

Actions of this module are weakly related to
one another, but strongly related to actions in
other modules.
– Consider sales district table

Not reusable
Slide 7.17
4. Procedural Cohesion


A module has procedural cohesion if it
performs a series of actions related by the
procedure to be followed by the product
Example
– read part number and update repair record on master file
Slide 7.18
Why Is Procedural Cohesion So Bad?

Actions are still weakly connected, so module is
not reusable
Slide 7.19
5. Communicational Cohesion


A module has communicational cohesion if it
performs a series of actions related by the
procedure to be followed by the product, but
in addition all the actions operate on the
same data
Example 1
– update record in database and write it to audit trail

Example 2
– calculate new coordinates and send them to terminal
Slide 7.20
Why Is Communicational Cohesion So Bad?

Still lack of reusability
Slide 7.21
7. Informational Cohesion

A module has informational cohesion if it
performs a number of actions, each with its
own entry point, with independent code for
each action, all performed on the same data
structure
Slide 7.22
Why Is Informational Cohesion So Good?


Essentially, this is an abstract data type
Optimal for the OO paradigm
Slide 7.23
7. Functional Cohesion


Module with functional cohesion performs
exactly one action
Example 1
– get temperature of furnace

Example 2
– compute orbital of electron

Example 3
– write to floppy disk

Example 4
– calculate sales commission
Slide 7.24
Why is functional cohesion so good?


More reusable
Corrective maintenance easier
– Fault isolation
– Fewer regression faults

Easier to extend product
Slide 7.25
Cohesion Case Study
Slide 7.26
Coupling


Degree of interaction between two modules
Five categories or levels of coupling
Slide 7.27
1. Content Coupling

Two modules are content coupled if one
directly references contents of the other

Example 1
– Module a modifies statement of module b

Example 2
– Module a refers to local data of module b in terms
of some numerical displacement within b

Example 3
– Module a branches into local label of module b
Slide 7.28
Why Is Content Coupling So Bad?

Almost any change to b, even recompiling b with
new compiler or assembler, requires change to a
Slide 7.29
2. Common Coupling

Two modules are common coupled if they have
write access to the same global data

Example 1
– Modules cca and ccb can access and change value of
global variable
Slide 7.30
2. Common Coupling (contd)

Example 2
– Modules cca and ccb both have access to same
database, and can both read and write same record

Example 3
– FORTRAN common
– COBOL common (nonstandard)
– COBOL-80 global
Slide 7.31
Why Is Common Coupling So Bad?

Contradicts the spirit of structured programming
– The resulting code is virtually unreadable
Slide 7.32
Why Is Common Coupling So Bad? (contd)

Modules can have side effects
– This affects their readability



If a maintenance change is made to a global data
in a module then every module that can access
that global data has to be changed
Difficult to reuse
Module exposed to more data than necessary
Slide 7.33
3. Control Coupling

Two modules are control coupled if one
passes an element of control to the other

Example 1
– Operation code passed to module with logical
cohesion

Example 2
– Control-switch passed as argument
Slide 7.34
Why Is Control Coupling So Bad?

Modules are not independent; module b
(the called module) must know internal
structure and logic of module a.
– Affects reusability

Associated with modules of logical cohesion
Slide 7.35
4. Stamp Coupling

Some languages allow only simple variables
as parameters
– part number
– satellite altitude
– degree of multiprogramming

Many languages also support passing of data
structures
– part record
– satellite coordinates
– segment table
Slide 7.36
4. Stamp Coupling (contd)

Two modules are stamp coupled if a data
structure is passed as a parameter, but the
called module operates on some but not all
of the individual components of the data
structure
Slide 7.37
Why Is Stamp Coupling So Bad?

It is not clear, without reading the entire module,
which fields of a record are accessed or changed
– Example
calculate withholding (employee record)



Difficult to understand
Unlikely to be reusable
More data than necessary is passed
– Uncontrolled data access can lead to computer crime

There is nothing wrong with passing a data
structure as a parameter, provided all the
components of the data structure are accessed
and/or changed
e.g., - invert matrix (original matrix, inverted matrix)
- print inventory record (warehouse record)
Slide 7.38
5. Data Coupling

Two modules are data coupled if all
parameters are homogeneous data items
(simple parameters, or data structures all
of whose elements are used by called
module)

Examples
– display time of arrival (flight number)
– compute multiplication (first number, second
number, result)
– get job with highest priority (job queue)
Slide 7.39
Why Is Data Coupling So Good?


The difficulties of content, common, control, and
stamp coupling are not present
Maintenance is easier
Slide 7.40
Coupling Case Study
Slide 7.41
Coupling Case Study (contd)

Interface description
Slide 7.42
Coupling Case Study (contd)

Coupling between all pairs of modules
Slide 7.43
Data Encapsulation

Example
– Design an operating system for a large mainframe
computer. It has been decided that batch jobs
submitted to the computer will be classified as high
priority, medium priority, or low priority. There must be
three queues for incoming batch jobs, one for each job
type. When a job is submitted by a user, the job is
added to the appropriate queue, and when the
operating system decides that a job is ready to be run, it
is removed from its queue and memory is allocated to it.

Design 1 (Next slide)
– Low cohesion—operations on job queues are spread all
over product
Slide 7.44
Data Encapsulation — Design 1
Slide 7.45
Data Encapsulation — Design 2
Slide 7.46
Data Encapsulation


has informational cohesion
m_encapsulation is an implementation of data
encapsulation
m_encapsulation
– Data structure (job_queue) together with
operations performed on that data structure

Advantages of using data encapsulation
– Development
– Maintenance
Slide 7.47
Data Encapsulation and Development


Data encapsulation is an example of abstraction
Job queue example
– Data structure
» job_queue
– Three new functions
» initialize_job_queue
» add_job_to_queue
» delete_job_from_queue

Abstraction
– Conceptualize problem at higher level
» job queues and operations on job queues
– not lower level
» records or arrays
Slide 7.48
Stepwise Refinement
1. Design in terms of high level concepts
– It is irrelevant how job queues are implemented
2. Design low level components
– Totally ignore what use will be made of them

In 1st step, assume existence of lower level
– Concern is the behavior of the data structure
» job_queue

In 2nd step, ignore existence of high level
– Concern is the implementation of that behavior

In a larger product, there will be many levels
of abstraction
Slide 7.49
Data Encapsulation and Maintenance


Identify aspects of product likely to change
Design product so as to minimize the effects of
change
– Data structures are unlikely to change
– Implementation may change

Data encapsulation provides a way to cope with
change
Slide 7.50
Implementation of Class JobQueue
C++
Java
Slide 7.51
Implementation of queueHandler
C++
Java
Slide 7.52
Data Encapsulation and Maintenance (contd)

What happens if queue is now implemented as a
two-way linked list of JobRecord?
– Module that uses JobRecord need not be changed at
all, merely recompiled
–
C++
Java
Slide 7.53
Abstract Data Types

Problem with both implementations
– Only one queue

Need
– We need:
Data type + operations performed on instantiations of
that data type

Abstract data type
Slide 7.54
Abstract Data Type

(Problems caused by public attributes solved later)
Slide 7.55
Information Hiding

Data abstraction
– Designer thinks at level of an ADT

Procedural abstraction
– Define a procedure—extend the language

Instances of a more general design concept,
information hiding (or details hiding)
– Design the modules in way that items likely to
change are hidden
– Future change is localized
– Changes cannot affect other modules
Slide 7.56
Information Hiding (contd)

C++ abstract
data type
implementation
with information
hiding
Slide 7.57
Information Hiding (contd)

Effect of information hiding via private attributes
Slide 7.58
Major Concepts of Chapter 7
Slide 7.59
Objects

First refinement
– Product is designed in terms of abstract data
types
– Variables (“objects”) are instantiations of
abstract data types

Second refinement
– Class: abstract data type that supports
inheritance
– Objects are instantiations of classes
Slide 7.60
Inheritance

Define humanBeing to be a class
– A humanBeing has attributes, such as age, height,
gender
– Assign values to attributes when describing object

Define Parent to be a subclass of HumanBeing
– A Parent has all attributes of a HumanBeing, plus attributes
of his/her own (name of oldest child, number of children)
– A Parent inherits all attributes of humanBeing

The property of inheritance is an essential feature
of object-oriented languages such as Smalltalk,
C++, Ada 95, Java (but not C, FORTRAN)
Slide 7.61
Inheritance (contd)

UML notation
– Inheritance is represented by a large open triangle
Slide 7.62
Java implementation
Slide 7.63
Aggregation

UML Notation
Slide 7.64
Association

UML Notation
Slide 7.65
Equivalence of Data and Action

Classical paradigm
– record_1.field_2

Object-oriented paradigm
– thisObject.attributeB
– thisObject.methodC ()
Slide 7.66
Polymorphism and Dynamic Binding

Classical paradigm
– Must explicitly invoke correct version
Slide 7.67
Polymorphism and Dynamic Binding (contd)
Object-oriented paradigm
Slide 7.68
Polymorphism and Dynamic Binding (contd)

All that is needed is myFile.open()
– Correct method invoked at run-time (dynamically)

Method open can be applied to objects of
different classes
– Polymorphic
Slide 7.69
Polymorphism and dynamic binding (contd)

Method checkOrder (b : Base) can be applied
to objects of any subclass of Base
Slide 7.70
Polymorphism and Dynamic Binding (contd)

Can have a negative impact on maintenance
– Code is hard to understand if there are multiple possibilities for a
specific method
– The cause of a failure can be very difficult to determine

Polymorphism and dynamic binding
– Strength and weakness of the object-oriented paradigm
Slide 7.71
Cohesion and Coupling of Objects

No new forms of cohesion or coupling
– Object-oriented cohesion and coupling always reduces
to classical cohesion

The only feature unique to the object-oriented
paradigm is inheritance
– Cohesion has nothing to do with inheritance
– Two objects with the same functionality have the same
cohesion
– It does not matter if this functionality is inherited or not
– Similarly, so-called object-oriented coupling always
reduces to classical coupling
Slide 7.72
Advantages of Objects

Same as advantages of abstract data types
– Information hiding
– Data abstraction
– Procedural abstraction

Inheritance provides further data abstraction
– Easier and less error-prone product development
– Easier maintenance

Objects are more reusable than modules with
functional cohesion
Slide 7.73
Summary
Slide 7.74
Summary
Slide 7.75