Software Design

and Architecture
CONCEPTS OF COHESION AND COUPLING
 Inheritance Coupling

Inheritance Coupling is better here – all inherited attributes are

needed.
Vehicle

description
serviceDate

LandVehicle AirVehicle

numberOfAxles maximumAltitude
registrationDate takeOffSpeed

checkAltitude()
register()
takeOff()
 3

Principle of Decoupling

 Tight coupling is usually bad

 Why?
 Hard to maintain
 Hard to extend
 Longer project compiling time
Cohesion

 Cohesion is a measure of the degree to which an element

contributes to a single purpose.

 The concepts of coupling and cohesion are not mutually exclusive

but actually support each other.

 Coad and Yourdon (1991) suggested several ways in which

coupling and cohesion can be applied within an object-oriented
approach.
 Operation Cohesion

Good operation cohesion but poor class cohesion

Lecturer

lecturerName
lecturerAddress
roomNumber
roomLength
roomWidth {return
roomLenght*
calculateRoomSpace()
roomWidth;}
 Poor Specialization Cohesion

Specialization Cohesion addresses the semantic cohesion of

inheritance hierarchies
Address

number
street
town
county
country
postCode

Person Company

personName companyName
age annualIncome
gender annualProfit
 Improved Structure

Improved structure using Address class.

Address

number
street
town
county
country
postCode

lives at is based at

Person Company

personName companyName
age annualIncome
gender annualProfit
 8

Example: which is better?

GraphicDisplaySystem GraphicDisplaySystem
• Less dependency
-drawCicle() +drawShapes() • Easy expansion
-drawRectange()
-drawTriangle() • Simplicity and
+drawShapes()
elegancy in
implementation
Shape Shape

+draw()

Rectangle Triangle Circle Rectangle Triangle Circle

+draw() +draw() +draw()

(a) (b)
 9

Promote Cohesion

 Cohesion: a class only performs closely related operations

 Why high cohesion?

 Logically good! Easy to maintain don’t distribute logically related

functions over multiple class!
 10
Example: An Initial Design of
Professor Class

Professor
-studentRecords : object
RegistrarOffice Student
-courseMaterials : object
+prepareGradApp() : object
-verifyDegree() : object
-adviseCurriculum() : object
AppForGraduation +getLectureNotes() : object StudentRecords
+getAssignment() : object

Assignment CourseMaterials LectureNote

 11

Business Logic Here

 Professor provides service to students

 Teaching
 Preparation of Graduation Applications
 Problem?
 The Professor class bears two functionalities
 Design is not co-hesive
 12

Improved Design

«interface»
«interface»
Instructor
Advisor
+getLectureNotes() : object
+prepareGradApp() : object
+getAssignments() : object
Professor
-studentRecords : object
-courseMaterials : object
RegistrarOffice +prepareGradApp() : object Student
-verifyDegree() : object
-adviseCurriculum() : object
AppForGraduation +getLectureNotes() : object StudentRecords
+getAssignment() : object

CourseMate
Assignment LectureNote
rials
Liskov Substitution Principle

 Essentially the principle states that, in object interactions, it should

be possible to treat a derived object as if it were a base object
without integrity problems.

 If the principle is not applied then it may be possible to violate

the integrity of the derived object
 Liskov Substitution Principle

Disinheritance of debit() means that the left-hand hierarchy is not

Liskov compliant
ChequeAccount
Account
accountName
balance accountName
balance
Restructuring
credit() to
debit() satisfy LSP credit()

MortgageAccount
MortgageAccount ChequeAccount
interestRate
interestRate
calculateInterest() debit()
- debit() calculateInterest()
 15

Open-Closed Principle

 Open to Extension
 The system can be extended to meet new requirements
 Close to Modification
 The existing implementation should not be modified
 How to do it?
 Inheritance and polymorphism
 16

Example

GraphicDisplaySystem GraphicDisplaySystem

-drawCicle() +drawShapes()
-drawRectange()
-drawTriangle()
+drawShapes()

Shape Shape

+draw()

Rectangle Triangle Circle Rectangle Triangle Circle

+draw() +draw() +draw()

(a) (b)
 17

Implications

 Separate interface and implementation

 Better to have an abstract interface class and then a concrete
class
 Depends on interface class only
 Keep attributes private
 Don’t expose attributes if not necessary
 Minimize the use of global variables
 Reduces coupling of modules
 18

Summary

 Concepts of Coupling

 Concepts of Cohesion

 Liskov Substitution Principle