Relations (1)

Relations, coupling, cohesion, and „ So far - design classes in isolation, except

refactoring „
„ type-hierarchies - organize semantically similar entities
Real-world objects related in many ways =>
other ways to abstract reality
„ Objects/classes need other objects/classes
„ Accessing functionality of other objects
Lecture 9: OOP, autumn 2003 „ Pass other object (its reference) as method parameter
„ Use super-class’s functionality
„ Access static methods
„ Use relationships between objects

Relations (2) Associations

„ Kinds of relations „ multiplicity
„ Association - general semantic relation between classes „ number of objects of one class per objects of other class
„ Binary, n-ary „ In UML - textual range expression
„ Bi-, single- directional „ Examples: ‘0..1’, ‘1..*’,
„ Can be recusrsive „ roles - how a class is viewed by other classes
„ Link „ constraints
„ an instance of an association
„ always between objects
„ Part-whole relations
„ anti-symmetric
„ transitive
„ Kinds: aggregation and composition

3 4

Association examples N-ary associations

association class

5 6

1
Aggregation Composition
„ Part-whole relationship „ Like aggregation
„ Objects exist independently „ But stronger - lifetime of part controlled by whole
„ No cycles in objects (anti-symmetry) „ Aggregate cardinality == 1
Implement through object references
„
„ Implement through object containment

7 8

Identifying association /aggregation Evaluating design quality

„ Start from requirements (use-cases) „ Questions
„ how modular is our design?
„ Search for: „ where does a method belong?
„ Things being part of other things => aggregations „ Are classes grouped properly into modules?
„ Verbs that describe relationships „ Many design ‘metrics’
e.g. ‘chages with’, ‘depends upon’, ‘which it gets from’ „ Cohesion
„ Look at sequence and other behavior diagrams „ Liskov: coherence
concerns relationships within a module
Take care
„
„
„ Coupling
„ Relate links to semantics „ concerns relationships between modules
„ Think of ‘good’ names for relations
„ Applicable at various level of detail: classes, modules
„ Goal: loosely coupled modules with high internal cohesion

9 10

Coupling (1) Coupling (2)

„ “Interconnectedness” „ Directly related to how hard it is to make
changes in a program (– “localizing” change)
„ The more one module has to “know” about another
module, the higher is the coupling between them „ Interfaces help separate “what” from “how”

„ Modules should be as independent as possible „ Proper encapsulation reduces coupling

Modules should communicate only via small, well
“Responsibility-driven design” (each unit
„
„
defined (“narrow”) interfaces
should handle its own data)

11 12

2
Code duplication Cohesion (1)
„ Sign of bad design „ A module should provide a well-defined task (service)
„ A module should have well-defined responsibilities
„ High cohesion facilitates reuse (well-defined modules)
„ Same code in two places => high coupling „ High cohesion simplifies modification (all relevant code in one
place)
High cohesion low coupling to other modules (but high coupling
Makes it difficult to modify and extend
„
„ within the module..)
„ Reducing coupling higher cohesion
„ Duplicated code often is an indication that a
When should we subdivide (and thus try to attain low coupling
better solution (in the implementation) is „
and between the different parts)?
possible (cf. “refactoring”) „ Subdivide when: You cannot keep all aspects of the module in
memory

13 14

Cohesion - classes Cohesion - methods

„ Do the methods take advantage of having direct access to the „ High cohesion
representation? „ short method
„ one task
„ descriptive name
„ Do the methods conceptually “belong” to the type? „ Possible indicators of low cohesion
„ difficult to describe what the method does
„ Is a method “doing the work” for some other class? „ difficult to to give the method a name
„ If-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 element
else
// return last element
}
15 16

Evolving a design - factorization Factorization by inheritance

„ Problem: code duplication „ If the code is in two different classes
„ Solution: ‘factor out’ code into method

17 18

3
Factorization by inheritance Factorization by delegation

19 20

Template method Template method example (1)

„ 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)
21 22

Template method example (2)

23