1. Objects First with Java
Designing classes
How to write classes in a way that they are easily understandable, maintainable and reusable
6.0
© David J. Barnes and Michael Kölling

2. Main concepts to be covered
Responsibility-driven design
Coupling
Cohesion
Refactoring
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

3. 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 (often decades).
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

4. 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.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

5. Code quality
It is possible to implement an application and to get it to perform its task with badly designed classes.
Just executing a finished application does not usually indicate whether it is structured well internally or not.
The problems typically surface when a maintenance programmer wants to make some changes to an existing application. If, for example, a programmer attempts to fix a bug, or wants to add new functionality to the program, a task that might be easy and obvious with well designed classes may well be very hard and involve a great deal of work if the classes are badly designed.

6. Code and design quality
Objects First with Java
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
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.
© David J. Barnes and Michael Kölling

7. Objects First with Java
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 hints at where coupling exists.
The degree of coupling determines how hard it is to make changes in an application. In a tightly coupled class structure, a change in one class can make it necessary to change several other classes as well. This is what we try to avoid, because the effect of making one small change can quickly ripple through a complete application. In addition, finding all the places where changes are necessary and actually making the changes can be difficult and time consuming.
In a loosely coupled system, on the other hand, we can often make changes to one class without making any changes to other classes, and the application will still work.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.
© David J. Barnes and Michael Kölling

8. Objects First with Java
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).
Ideally, one unit of code should be responsible for one cohesive task (that is, one task that can be seen as a logical unit).
The main reason behind the principle of cohesion is reuse: if a method or class is responsible for only one well-defined thing, then it is much more likely that it can be used again in a different context. A complementary advantage of following this principle is that, when change is required to some aspect of an application, we are likely to find all the relevant pieces located in the same unit.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.
© David J. Barnes and Michael Kölling

9. 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.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

10. Reducing coupling Encapsulation supports loose coupling.
private elements cannot be referenced from outside the class.
Reduces the impact of internal changes.
Responsibility-driven design supports loose coupling.
Driven by data location.
Enhanced by encapsulation.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

11. 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.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

12. 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.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

13. Implicit coupling
Linkage not necessarily expressed via data and method interactions.
Can arise from assumptions about the way a class is implementing.
Satisfactory resolution might require a small increase in explicit coupling.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

14. Cohesion (reprise)
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).
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

15. Objects First with Java
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.
The main reason behind the principle of cohesion is reuse: if a method or class is responsible for only one well-defined thing, then it is much more likely that it can be used again in a different context. A complementary advantage of following this principle is that, when change is required to some aspect of an application, we are likely to find all the relevant pieces located in the same unit.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.
© David J. Barnes and Michael Kölling

16. Loose cohesion We aim to avoid loosely cohesive classes and methods:
Methods performing multiple tasks.
Classes modeling multiple entities.
Classes having no clear identity.
Modules/Packages of unrelated classes.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

17. 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.
Module/Package level:
Groups of related classes.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

18. Objects First with Java
Code duplication
An indicator of bad design.
Makes maintenance harder.
Can lead to the introduction of inconsistencies and errors during maintenance/modification.
Occurs at both method and class level.
The problem with code duplication is that any change to one version must also be made to the other if we are to avoid inconsistency. This increases the amount of work a maintenance programmer has to do, and it introduces the danger of bugs. It happens very easily that a maintenance programmer finds one copy of the code and, having changed it, assumes that the job is done. There is nothing indicating that a second copy of the code exists, and it might incorrectly remain unchanged.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.
© David J. Barnes and Michael Kölling

19. Thinking ahead
When designing a class, we try to think about changes likely to be made in the future.
We aim to make those changes easy.
Requires a little more effort now to greatly reduce effort later.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

20. Refactoring When classes are maintained code is usually added.
Classes and methods tend to become longer.
Every now and then, classes and methods should be refactored to maintain cohesion and low coupling.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

21. 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.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

22. Design questions Common questions:
How long should a class be?
How long should a method be?
These can now be answered in terms of cohesion and coupling.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

23. 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.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

24. Enumerated Types A language feature.
Uses enum instead of class to introduce a type name.
Their simplest use is to define a set of significant names.
Alternative to static int constants.
When the constants’ values would be arbitrary.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

25. 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 enum type, e.g., CommandWord.HELP.
Enum objects are not created directly.
Enum definitions can also have fields, constructors and methods.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

26. 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.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

27. Review
Good quality code avoids duplication, displays high cohesion, 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.
© 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.