Comp1004: Building Better Classes II

Comp1004: Building Better Classes II Software 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

Duplication public void getTotal(int[] array) { inttotalcost = 0; for(int n : array){ totalcost+= n; } return totalcost; } public void getTotalIncVAT(int[] array) { inttotalcost = 0; for(int n : array){ totalcost += n; } totalcost = totalcost * 1.2; return totalcost; }

Duplication public void getTotal(int[] array) { inttotalcost = 0; for(int n : array){ totalcost+= n; } return totalcost; } public void getTotalIncVAT(int[] array) { inttotalcost = 0; for(int n : array){ totalcost += n; } totalcost = totalcost * 1.2; return totalcost; } Code Duplication is an indicator of bad design Makes maintenance harder and can lead to the introduction of errors What is a better solution?

Duplication public void getTotal(int[] array) { inttotalcost = 0; for(int n : array){ totalcost+= n; } return totalcost; } public void getTotalIncVAT(int[] array) { inttotalcost = getTotal(array); totalcost = totalcost * 1.2; return totalcost; } 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? Household Plumbing The Human Body

Real World Examples Are these tightly or loosely coupled systems? 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 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). Household Plumbing The Human Body

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); intnumDaysInMilliseconds = startDate.compareTo(endDate); intnumDays = numDaysInMilliseconds/ (1000 * 60 * 60 * 24); System.out.println(“Nights in total: ” + numDays); System.out.println(“Total cost: ” + getCost(numDays)); } }

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); intnumDaysInMilliseconds = startDate.compareTo(endDate); intnumDays = numDaysInMilliseconds/ (1000 * 60 * 60 * 24); System.out.println(“Nights in total: ” + numDays); System.out.println(“Total cost: ” + getCost(numDays)); } } Cohesion of Methods A method should be responsible for one and only one well defined task. Is this method cohesive?

public class DogBooking { protected String name; protected String breed; protected String ownersname; protected Calendar startDate; protected Calendar endDate; //some code omitted public void printInvoice() { printDetails(); intnumDays = getNumberOfDays(); System.out.println(“Nights in total: ” + numDays); System.out.println(“Total cost: ” + getCost(numDays)); } public void printDetails() { System.out.println(name + “, ” + breed); } public intgetNumberOfDays() { intnumDaysInMilliseconds = startDate.compareTo(endDate); return numDaysInMilliseconds / (1000 * 60 * 60 * 24); } } Cohesion of Methods A method should be responsible for one and only one well defined task. Is this method cohesive? Arguably it does three things – so it would be better to pull the other two out into separate methods

public class DogBooking { protected String name; protected String breed; protected String ownersname; protected Calendar startDate; protected Calendar endDate; //some code omitted public void printInvoice() { printDetails(); intnumDays = getNumberOfDays(); System.out.println(“Nights in total: ” + numDays); System.out.println(“Total cost: ” + getCost(numDays)); } public void printDetails() { System.out.println(name + “, ” + breed); } public intgetNumberOfDays() { intnumDaysInMilliseconds = startDate.compareTo(endDate); return numDaysInMilliseconds / (1000 * 60 * 60 * 24); } } Cohesion of Classes Classes should represent one single, well defined entity. Is this class cohesive?

public class Dog { protected String name; protected String breed; protected String ownersname; //some code omitted public void printDetails() { System.out.println(name + “, ” + breed); } } public class Booking { protected Dog dog; protected Calendar startDate; protected Calendar endDate; //some code omitted public void printInvoice() { dog.printDetails(); intnumDays = getNumberOfDays(); System.out.println(“Nights in total: ” + numDays); System.out.println(“Total cost: ” + getCost(numDays)); } public intgetNumberOfDays() { intnumDaysInMilliseconds= startDate.compareTo(endDate); return numDaysInMilliseconds/ (1000 * 60 * 60 * 24); } } Cohesion of Classes Classes should represent one single, well defined entity. 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 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 public void switchOffElectrics() { //switch off all four lights Lights[] lights = getLights(); lights[0].switchOff(); lights[1].switchOff(); lights[2].switchOff(); lights[3].switchOff(); //setHeatingtoMinimum HeatingControlhc = getHeatingControl(); hc.setThermoStat(18); } What might we change here?

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 public void switchOffElectrics() { //switch off all lights Lights[] lights = getLights(); for(Light light : lights) { light.switchOff(); } //setHeatingtoMinimum HeatingControlhc = getHeatingControl(); hc.setThermoStat(18); } What might we change here? Use a loop to switch off the lights – now it doesn’t matter how many we have

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 public void switchOffElectrics() { //switch off all lights Lights[] lights = getLights(); for(Light light : lights) { light.switchOff(); } //setHeatingtoMinimum HeatingControlhc = getHeatingControl(); hc.setThermoStat(getLowTemperature()); } protected intgetLowTemperature() { //low is currently defined as 18 return 18; } What might we change here? 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.

Comp1004: Building Better Classes II