Relations, coupling, cohesion, and refactoring

Lecture 9: OOP, autumn 2003

2

Relations (1)So far - design classes in isolation, except

type-hierarchies - organize semantically similar entities

Real-world objects related in many ways =>other ways to abstract realityObjects/classes need other objects/classesAccessing functionality of other objects

Pass other object (its reference) as method parameterUse super-class’s functionalityAccess static methodsUse relationships between objects

3

Relations (2)

Kinds of relationsAssociation - general semantic relation between classes

Binary, n-aryBi-, single- directionalCan be recusrsive

Linkan instance of an associationalways between objects

Part-whole relationsanti-symmetrictransitiveKinds: aggregation and composition

4

Associationsmultiplicity

number of objects of one class per objects of other classIn UML - textual range expressionExamples: ‘0..1’, ‘1..*’,

roles - how a class is viewed by other classesconstraints

5

Association examples

6

N-ary associations

association class

7

AggregationPart-whole relationshipObjects exist independentlyNo cycles in objects (anti-symmetry)Implement through object references

8

CompositionLike aggregationBut stronger - lifetime of part controlled by wholeAggregate cardinality == 1Implement through object containment

9

Identifying association /aggregation

Start from requirements (use-cases)Search for:

Things being part of other things => aggregationsVerbs that describe relationshipse.g. ‘chages with’, ‘depends upon’, ‘which it gets from’Look at sequence and other behavior diagrams

Take careRelate links to semanticsThink of ‘good’ names for relations

10

Evaluating design qualityQuestions

how modular is our design?where does a method belong?Are classes grouped properly into modules?

Many design ‘metrics’Cohesion

Liskov: coherenceconcerns relationships within a module

Couplingconcerns relationships between modules

Applicable at various level of detail: classes, modulesGoal: loosely coupled modules with high internal cohesion

11

Coupling (1)

“Interconnectedness”

The more one module has to “know” about anothermodule, the higher is the coupling between them

Modules should be as independent as possible

Modules should communicate only via small, welldefined (“narrow”) interfaces

12

Coupling (2)

Directly related to how hard it is to make changes in a program (– “localizing” change)

Interfaces help separate “what” from “how”

Proper encapsulation reduces coupling

“Responsibility-driven design” (each unit should handle its own data)

13

Code duplication

Sign of bad design

Same code in two places => high coupling

Makes it difficult to modify and extend

Duplicated code often is an indication that a better solution (in the implementation) is possible (cf. “refactoring”)

14

Cohesion (1)A module should provide a well-defined task (service)A module should have well-defined responsibilitiesHigh cohesion facilitates reuse (well-defined modules)High cohesion simplifies modification (all relevant code in one place)High cohesion low coupling to other modules (but high coupling within the module..)Reducing coupling higher cohesion

When should we subdivide (and thus try to attain low coupling and between the different parts)?Subdivide when: You cannot keep all aspects of the module in memory

15

Cohesion - classesDo the methods take advantage of having direct access to the representation?

Do the methods conceptually “belong” to the type?

Is a method “doing the work” for some other class?

16

Cohesion - methodsHigh cohesion

short methodone taskdescriptive name

Possible indicators of low cohesiondifficult to describe what the method doesdifficult to to give the method a nameIf-then-else, switch

/** This returns the the first or last element of an ordered collection, depending on flag. */

Object getEnd(List l, boolean firstFlag) {if (firstFlag)// return first elementelse// return last element}

17

Evolving a design - factorization

Problem: code duplicationSolution: ‘factor out’ code into method

18

Factorization by inheritance

If the code is in two different classes

19

Factorization by inheritance

20

Factorization by delegation

21

Template method

Defines the skeleton of an algorithm

Allows for subclasses to redefine certain steps of the algorithm without changing it’s structure

Useful in situations when you have unique code inside a section of duplicate code (i.e. where simple factorization doesn’t work)

22

Template method example (1)

23

Template method example (2)