Chapter 7

Designing Classes

Class Design• When we are developing a piece

of software, we want to design the software

• We don’t want to just sit down and bang on the keyboard for a while

• We want to think about what we are going to be writing first and then type

What should we be thinking about?• There are 3 main things we

should think about1. Code Quality 2. Responsibility-driven design3. Refactoring

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).

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.

Code quality• Two important concepts for quality of

code:

1. Coupling2. Cohesion

• These are related topics, but different ideas and sometime difficult to grasp.

• Code duplication is a third minor concept for code quality.

• If you have good coupling and cohesion, code duplication will be less of an issue.

CouplingCoupling describes the

interconnectedness of classes• We strive for loose coupling• Each class should be largely

independent of the other classes in the system

• Communication should be done through a well defined interface.

Cohesion• Cohesion refers to how well a unit

of code maps to a logical task.• Each unit of code (method, class

or module) is responsible for a well-defined task.

• There are two main types of cohesion– Method– Class

Method Cohesion• Method cohesion refers to how

well does a method do its job.• In general, each method should do

one thing and do it well.• You can build up bigger methods

from smaller ones.

Class Cohesion• How well does a class do its job.• Each class should focus on one

idea and do it well.• Classes should represent one noun

from the project scope.• For example, a CD class can be

used to store tracks, as do real CDs• You shouldn’t try to make a CD

into a Frisbee.• It’s not what it was designed to do

and it doesn’t do it very well.

Code Duplication• Code duplication is an indicator of

bad design• The problem is that any change to

one piece of code requires changes to all places where that code is located

• It is easy to forget to change all the locations

• Worse yet, if you are working on someone else’s code, you may not know that the code duplication exists

Responsibility-Driven Design• Responsibility-driven design

expresses the idea that each class should be responsible for handling its own data.

• We can use this notion to determine which classes should implement a piece of functionality.

• If a class has the information necessary to process something, then it should do so.

• We can use this idea to decide where to put a method.

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 cohesion and low coupling.

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.

Design questionsCommon questions:• How long should a class be?• How long should a method be?

• Can now be answered in terms of cohesion and coupling.

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.

Making Extensions• How well or poorly designed a class

is, is sometimes very evident when you want to make extensions to a class.

• The question often comes up, how extensible is a class?

• A class that can be extended easily, was probably designed with care.

• A class that cannot be extended easily, may have been designed quickly, with little thought to how it might be extended.

Encapsulation• Encapsulation is a major idea

behind OOP• Encapsulation suggests that only

information about what a class can do should be visible to the outside

• How it does what it does should be hidden from the user of the object

• This is why we want to have our fields be private instead of public

Executing without BlueJ• So far all we have done is write

classes that can de run inside of BlueJ

• You might write a program one day that you want other people to be able to use

• In order to do that, you need to learn about class methods

Class Methods• A class method is a method that

can be run without an instance of the class

• Every Java program will have at least one class method, the main method

• public static void main( String[ ] Args )

Class Methods• Any method that is declared to be

static is a class method• This will allow you to call a

method without have an object around

• We saw one of these the other day: Math.abs()

• Also, System.out.println()

Limitations to Class Methods• Since you don’t have an object

around, static methods cannot use any variable that is not also declared to be static

• Also a static method may not call any other method that is not declared to be static.