Relations, coupling, cohesion, and refactoring · 2003. 11. 25. · 2 Relations (1) So far - design...
Transcript of Relations, coupling, cohesion, and refactoring · 2003. 11. 25. · 2 Relations (1) So far - design...
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)