comp1004 building better classes ii n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Comp1004: Building Better Classes II PowerPoint Presentation
Download Presentation
Comp1004: Building Better Classes II

Loading in 2 Seconds...

play fullscreen
1 / 30

Comp1004: Building Better Classes II - PowerPoint PPT Presentation


  • 58 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Comp1004: Building Better Classes II' - rayya


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
comp1004 building better classes ii

Comp1004: Building Better Classes II

Software Design

Partly based on BlueJ Book – Chapter 7

coming up
Coming Up
  • Duplication
  • Coupling
  • Cohesion
  • Responsibility-driven design
  • Refactoring
software changes
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
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
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;

}

duplication1
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?

duplication2
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
  • 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
  • Loose coupling makes it possible to:
    • understand one class without reading others;
    • change one class without affecting others.
    • Thus: improves maintainability.
real world examples
Real World Examples

Are these tightly or loosely coupled systems?

Household Plumbing

The Human Body

real world examples1
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
  • 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
  • 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
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 design1
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

slide16

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

}

}

slide17

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?

slide18

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

slide19

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?

slide20

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
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
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 ahead1
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 ahead2
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
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
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
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
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
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.
summary1
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.