Comp1004: Building Better Classes II

Comp1004: Building Better Classes IISoftware Design

Partly based on BlueJ Book – Chapter 7

Coming Up

• Duplication• Coupling• Cohesion• Responsibility-driven design• 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.

• Three important concepts for quality of code:– Duplication– Coupling– Cohesion

Duplicationpublic void getTotal(int[] array) {

int totalcost = 0;

for(int n : array){totalcost += n;

}return totalcost;

}

public void getTotalIncVAT(int[] array) {int totalcost = 0;


}

totalcost = totalcost * 1.2;return totalcost;

}


int totalcost = 0;


}return totalcost;

}

public void getTotalIncVAT(int[] array) {int totalcost = 0;


}


}

Code Duplication is an indicator of bad design

Makes maintenance harder and can lead to the introduction of errors

What is a better solution?


int totalcost = 0;


}return totalcost;

}

public void getTotalIncVAT(int[] array) {int totalcost = getTotal(array);


}

Code Duplication is an indicator of bad design

Makes maintenance harder and can lead to the introduction of errors

What is a better solution?

Use methods to write code once and call many times

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.

Loose coupling

• Loose coupling makes it possible to:– understand one class without reading others;– change one class without affecting others.– Thus: improves maintainability.

Real World Examples

Are these tightly or loosely coupled systems?

The Human BodyHousehold Plumbing

Real World Examples

Are these tightly or loosely coupled systems?

The Human BodyHousehold Plumbing

Loosely Coupled

Modular, each section is independent and linked to the whole through a simple

interface. So it is easy to change one bit without breaking the rest (within reason).

Tightly Coupled

Each part is linked in thousands of ways to the whole. This creates excellent performance and is very efficient, but makes it difficult to maintain

Cohesion

• Cohesion refers to the 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.

• Cohesion applies to classes and methods.• We aim for high cohesion.

High cohesion

• High cohesion makes it easier to:– understand what a class or method does;– use descriptive names;– reuse classes or methods.

Cohesion of Methods

A method should be responsible for one and only one well defined task.

Cohesion of Classes

Classes should represent one single, well defined entity.

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 and high cohesion

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.

Encapsulation

public class DogBooking {protected String name;protected String breed;protected String ownersname;protected Calendar startDate;protected Calendar endDate;

//some code omitted

public void printInvoice() {System.out.println(name + “, ” + breed);

int numDaysInMilliseconds = startDate.compareTo(endDate);int numDays = numDaysInMilliseconds / (1000 * 60 * 60 * 24);

System.out.println(“Nights in total: ” + numDays);System.out.println(“Total cost: ” + getCost(numDays));

}}


//some code omitted

public void printInvoice() {System.out.println(name + “, ” + breed);

int numDaysInMilliseconds = startDate.compareTo(endDate);int numDays = numDaysInMilliseconds / (1000 * 60 * 60 * 24);


}}

Cohesion of Methods


Is this method cohesive?


//some code omitted

public void printInvoice() {printDetails();

int numDays = getNumberOfDays();


}

public void printDetails() {System.out.println(name + “, ” + breed);

}

public int getNumberOfDays() {int numDaysInMilliseconds = startDate.compareTo(endDate);return numDaysInMilliseconds / (1000 * 60 * 60 * 24);

}

}

Cohesion of Methods


Is this method cohesive?

Arguably it does three things – so it would be better to pull the other two out into separate methods


//some code omitted

public void printInvoice() {printDetails();



}


}


}

}

Cohesion of Classes


Is this class cohesive?

public class Dog {protected String name;protected String breed;protected String ownersname;

//some code omitted


}}

public class Booking {protected Dog dog;protected Calendar startDate;protected Calendar endDate;

//some code omitted

public void printInvoice() {dog.printDetails();



}


}}

Cohesion of Classes


Is this class cohesive?

Arguably it is better represented by two classes – one to hold the details of the dog, the other the details of the booking

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.

Thinking aheadpublic void switchOffElectrics() {

//switch off all four lightsLights[] lights = getLights();

lights[0].switchOff();lights[1].switchOff();lights[2].switchOff();lights[3].switchOff();

//setHeatingtoMinimumHeatingControl hc = getHeatingControl();hc.setThermoStat(18);

}

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

What might we change here?


//switch off all lightsLights[] lights = getLights();

for(Light light : lights) {light.switchOff();

}

//setHeatingtoMinimumHeatingControl hc = getHeatingControl();hc.setThermoStat(18);

}




Use a loop to switch off the lights – now it doesn’t matter how many we have


//switch off all lightsLights[] lights = getLights();

for(Light light : lights) {light.switchOff();

}

//setHeatingtoMinimumHeatingControl hc = getHeatingControl();hc.setThermoStat(getLowTemperature());

}

protected int getLowTemperature() {//low is currently defined as 18return 18;

}




Use a loop to switch off the lights – now it doesn’t matter how many we have

Hide the low temperature behind another method – in case it changes in the future

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 questions

• Common 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.

Summary

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

Summary

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

Documents

Comp1004: Building Better Classes II