1. Objektorienterad programmering d2, förel. 8
8 Designing classes
BK Chap. 8
How to write classes that are easily understandable, maintainable and reusable
DAT050, DAI2, 16/17, lp 1

2. Main concepts to be covered
Objektorienterad programmering d2, förel. 8
Main concepts to be covered
Responsibility-driven design
Coupling
Cohesion
Refactoring
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

3. Objektorienterad programmering d2, förel. 8
Software changes
Software is not like a novel that is written once and then remains unchanged
Software is extended, corrected, maintained, ported, adapted …
The work is done by different people over time
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

4. Objektorienterad programmering d2, förel. 8
Change or die
There are only two options for software:
Either it is continuously maintained
or it dies
Software that cannot be maintained will be thrown away
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

5. Objektorienterad programmering d2, förel. 8
World of Zuul
Explore zuul-bad
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

6. Objektorienterad programmering d2, förel. 8
The Zuul Classes
Game: The starting point and main control loop
Room: A room in the game
Parser: Reads user input
Command: A user command
CommandWords: Recognized user commands
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

7. An example to test quality
Objektorienterad programmering d2, förel. 8
An example to test quality
Add two new directions to the 'World of Zuul':
“up”
“down”
What do you need to change to do this?
How easy are the changes to apply thoroughly?
Låt varje rum innehålla ett föremål med beskrivning och vikt
Är det bra design att införa attribut för detta i Room?
TÄNK FRAMÅT!
- Kan föremålet bäras iväg?
- Kan man ha flera föremål?
Inför klassen Item!
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
Kör resten av bilderna
- Sen DEMO
DAT050, DAI2, 16/17, lp 1

8. Code and design quality
Objektorienterad programmering d2, förel. 8
Code and design quality
If we are to be critical of code quality, we need evaluation criteria
Two important concepts for assessing the quality of code are:
Coupling
Cohesion
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

9. Objektorienterad programmering d2, förel. 8
Coupling
Coupling refers to links between separate units of a program
If two classes depend closely on many details of each other, we say they are tightly coupled
We aim for loose coupling
A class diagram provides (limited) hints at the degree of coupling
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

10. Objektorienterad programmering d2, förel. 8
Cohesion
Cohesion refers to the number and diversity of tasks that a single unit is responsible for
If each unit is responsible for one single logical task, we say it has high cohesion
We aim for high cohesion
‘Unit’ applies to classes, methods and modules (packages)
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

11. Objektorienterad programmering d2, förel. 8
Cohesion ”on the road”
Which brake system design has the highest cohesion?
Återvänd till detta efter sista bilden (före demon).
I fälgbromsen är fälgen den passiva delen i bromsen. Pga denna design måste hjulet bytas ut vid slitage.
Hjulet har fått en extra roll som komponent i ett annat system (bromssystemet).
Skivbromsen är designad som ett eget väl sammanhållet system. Alla förslitningsdetaljer hör till själva bromsen. Slitage i bromsen påverkar inga andra komponenter.
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

12. Objektorienterad programmering d2, förel. 8
Loose coupling
We aim for loose coupling
Loose coupling makes it possible to:
understand one class without reading others;
change one class with little or no effect on other classes
Thus: loose coupling increases maintainability
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

13. Objektorienterad programmering d2, förel. 8
Tight coupling
We try to avoid tight coupling
Changes to one class bring a cascade of changes to other classes
Classes are harder to understand in isolation
Flow of control between objects of different classes is complex
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

14. Objektorienterad programmering d2, förel. 8
High cohesion
We aim for high cohesion
High cohesion makes it easier to:
understand what a class or method does
use descriptive names for variables, methods and classes
reuse classes and methods
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

15. Objektorienterad programmering d2, förel. 8
Loose cohesion
We aim to avoid loosely cohesive classes and methods:
Methods performing multiple tasks
Classes having no clear identity
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

16. Objektorienterad programmering d2, förel. 8
Summary
Coupling
Cohesion
Tight/High  
Loose/Low
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

17. Cohesion applied at different levels
Objektorienterad programmering d2, förel. 8
Cohesion applied at different levels
Class level:
Classes should represent one single, well defined entity
Method level:
A method should be responsible for one and only one well defined task
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

18. Objektorienterad programmering d2, förel. 8
Code duplication
Code duplication
is an indicator of bad design
makes maintenance harder
can lead to introduction of errors during maintenance
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

19. Responsibility-Driven Design
Objektorienterad programmering d2, förel. 8
Responsibility-Driven Design
Question: where should we add a new method (which class)?
Each class should be responsible for manipulating its own data
The class that owns the data should be responsible for processing it
RDD leads to low coupling
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

20. Objektorienterad programmering d2, förel. 8
Localizing change
One aim of reducing coupling and responsibility-driven design is to localize change
When a change is needed, as few classes as possible should be affected
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

21. Objektorienterad programmering d2, förel. 8
Thinking ahead
When designing a class, we try to think what changes are likely to be made in the future
We aim to make those changes easy
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

22. Objektorienterad programmering d2, förel. 8
Refactoring
When classes are maintained, often code is added
Classes and methods tend to become longer
Every now and then, classes and methods should be refactored to maintain high cohesion and low coupling
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

23. Refactoring and testing
Objektorienterad programmering d2, förel. 8
Refactoring and testing
When refactoring code, separate the refactoring from making other changes
First do the refactoring only, without changing the functionality
Test before and after refactoring to ensure that nothing was broken
Refactor
Test!
Change
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

24. Objektorienterad programmering d2, förel. 8
Design questions
Common questions:
How long should a class be?
How long should a method be?
These can be answered in terms of cohesion and coupling
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

25. Objektorienterad programmering d2, förel. 8
Design guidelines
A method is too long if it does more then one logical task
A class is too complex if it represents more than one logical entity
Note: these are guidelines - they still leave much open to the designer
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

26. Objektorienterad programmering d2, förel. 8
Enumerated Types BK
A language feature
Uses enum instead of class to introduce a type name
A common use is to define a set of significant names
Alternative to static int constants (When the constants’ values would be arbitrary.)
Se BK 7.13 !
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

27. A basic enumerated type
Objektorienterad programmering d2, förel. 8
A basic enumerated type
public enum CommandWord {
// A value for each command word,
// plus one for unrecognised commands.
GO, QUIT, HELP, UNKNOWN; }
Each name represents an object of the enumerated type, e.g. CommandWord.HELP
Enum objects are not created directly by the programmer
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

28. Objektorienterad programmering d2, förel. 8
Review
Programs are continuously changed.
It is important to make this change possible
Quality of code requires much more than just performing correct at one time
Code must be understandable and maintainable
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1

29. Objektorienterad programmering d2, förel. 8
Review
Good quality code avoids duplication, displays high cohesion and low coupling
Coding style (commenting, naming, layout, etc.) is also important
There is a big difference in the amount of work required to change poorly structured and well structured code
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, DAI2, 16/17, lp 1