Presentation is loading. Please wait.

Presentation is loading. Please wait.

Design: Coupling and Cohesion How to write classes in a way that they are easily understandable, maintainable and reusable.

Similar presentations


Presentation on theme: "Design: Coupling and Cohesion How to write classes in a way that they are easily understandable, maintainable and reusable."— Presentation transcript:

1 Design: Coupling and Cohesion How to write classes in a way that they are easily understandable, maintainable and reusable

2 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Main concepts to be covered Responsibility-driven design Responsibility-driven design Coupling Coupling Cohesion Cohesion Refactoring Refactoring Enumerations Enumerations 2

3 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Software changes Software is not like a novel that is written once and then remains unchanged. Software is not like a novel that is written once and then remains unchanged. Software is extended, corrected, maintained, ported, adapted … Software is extended, corrected, maintained, ported, adapted … The work is done by different people over time (often decades). The work is done by different people over time (often decades). 3

4 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Change or die There are only two options for software: There are only two options for software: Either it is continuously maintained...Either it is continuously maintained... Or it diesOr it dies Software that cannot be maintained will be thrown away. Software that cannot be maintained will be thrown away. 4

5 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling World of Zuul 5 Chapter 7: zuul-bad

6 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling An Example Add two new directions to the World of Zuul: Add two new directions to the World of Zuul: upup downdown What do you need to change to do this? What do you need to change to do this? 6

7 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Code Quality Two important concepts for quality of code: Two important concepts for quality of code: Coupling – as little as possible please Coupling – as little as possible please Cohesion – as much as possible please Cohesion – as much as possible please 7

8 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Coupling Coupling refers to links between separate units of a program. 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. If two classes depend closely on many details of each other, we say they are tightly coupled. We aim for loose coupling. We aim for loose coupling. 8

9 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Loose Coupling Loose coupling makes it possible to: Loose coupling makes it possible to: understand how to use a class without having to understand how that class works;understand how to use a class without having to understand how that class works; change the implementation of a class without affecting those classes that use it.change the implementation of a class without affecting those classes that use it. This improves maintainability … makes change easier. 9

10 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Cohesion Cohesion relates to: the the number and diversity of tasks for which a single unit is responsible. Cohesion relates to: the the number and diversity of tasks for which a single unit is responsible. If a programming unit is responsible for one logical task, we say it has high cohesion. If a programming unit is responsible for one logical task, we say it has high cohesion. Cohesion applies both at the level of classes and of methods. Cohesion applies both at the level of classes and of methods. We aim for high cohesion. We aim for high cohesion. 10

11 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling High Cohesion High cohesion makes it easier to: High cohesion makes it easier to: understand what a class or method does (because it only does one thing);understand what a class or method does (because it only does one thing); Choose and use descriptive names;Choose and use descriptive names; reuse classes or methods.reuse classes or methods. This improves usability … and makes change easier. 11

12 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Cohesion of Classes Classes should represent just one, and only one, well defined entity. Cohesion of Methods A method should be responsible for one, and only one, well defined task. 12

13 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Code Duplication This is an indicator of bad design. It makes maintenance harder. It can lead to introduction of errors, especially during maintenance. 13

14 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling World of Zuul Chapter 7: zuul-bad Add up and down exits?

15 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Chapter 7: zuul-bad Problems Fields in Room are all public. Fields in Room are all public. The fact that a Room has four exits is burnt into the interface of its setExits method. The fact that a Room has four exits is burnt into the interface of its setExits method. The Game class references Room fields. The Game class references Room fields. So, the implementation of the Game and Room classes are coupled. A change in one (e.g. adding more exits to a Room ) means changing the other (e.g. the createRooms, printWelcome and goRoom methods of Game ). So, the implementation of the Game and Room classes are coupled. A change in one (e.g. adding more exits to a Room ) means changing the other (e.g. the createRooms, printWelcome and goRoom methods of Game ). This is BAD! This is BAD!

16 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Chapter 7: zuul-bad Problems There are duplicated code fragments in the Game class (in createRooms and printWelcome methods). There are duplicated code fragments in the Game class (in createRooms and printWelcome methods). Changing the details of one of these fragments means changing all. Changing the details of one of these fragments means changing all. This is BAD! This is BAD! Factorise the duplicated code into a single method (see Code 7.2, p209, of the book: printLocationInfo ) and duplicate its invocation instead. Factorise the duplicated code into a single method (see Code 7.2, p209, of the book: printLocationInfo ) and duplicate its invocation instead. Now, there is only one fragment of code to maintain. This is Good! Now, there is only one fragment of code to maintain. This is Good!

17 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Chapter 7: zuul-bad There are duplicated code fragments in the Game class (in createRooms and printWelcome methods). There are duplicated code fragments in the Game class (in createRooms and printWelcome methods). Changing the details of one of these fragments means changing all. Changing the details of one of these fragments means changing all. This is BAD! This is BAD! Factorise the duplicated code into a single method (see Code 7.2 of the book: printLocationInfo ) and duplicate its invocation instead. Factorise the duplicated code into a single method (see Code 7.2 of the book: printLocationInfo ) and duplicate its invocation instead. Now, there is only one fragment of code to maintain. This is Good! Now, there is only one fragment of code to maintain. This is Good!  Chapter 7: zuul-better

18 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Chapter 7: zuul-bad  Make fields in Room private and provide accessor methods to get them (e.g. getExit in Code 7.4). Make fields in Room private and provide accessor methods to get them (e.g. getExit in Code 7.4). In Game, can no longer reference directly the exit fields (all Room s) of Room. In Game, can no longer reference directly the exit fields (all Room s) of Room. In Game. printLocationInfo (which does so reference), we could just change it to use the accessor method, rather than the field. In Game. printLocationInfo (which does so reference), we could just change it to use the accessor method, rather than the field. However, it’s neater to invoke a (new) method of Room to get the exit information it needs to print (Code 7.6). Each Room object has that information, so it is really its responsibility. However, it’s neater to invoke a (new) method of Room to get the exit information it needs to print (Code 7.6). Each Room object has that information, so it is really its responsibility. For Game. goRoom (which also does so reference), thirteen lines of code collapse to one (see p214 in “Fourth Edition”, but p201 in “Third Edition”). For Game. goRoom (which also does so reference), thirteen lines of code collapse to one (see p214 in “Fourth Edition”, but p201 in “Third Edition”). Chapter 7: zuul-better

19 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Chapter 7: zuul-bad  Make fields in Room private and provide accessor methods to get them (e.g. getExit in Code 7.4). Make fields in Room private and provide accessor methods to get them (e.g. getExit in Code 7.4). Chapter 7: zuul-better Look carefully at this getExit accessor … Look carefully at this getExit accessor …

20 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling public Room getExit (String direction) { if (direction.equals ("north")) { return northExit; } if (direction.equals ("east")) { return eastExit; } if (direction.equals ("south")) { return southExit; } if (direction.equals ("west")) { return westExit; } if (direction.equals ("south")) { return southExit; } if (direction.equals ("west")) { return westExit; } return null; return null;} public Room getExit (String direction) { if (direction.equals ("north")) { return northExit; } if (direction.equals ("east")) { return eastExit; } if (direction.equals ("south")) { return southExit; } if (direction.equals ("west")) { return westExit; } if (direction.equals ("south")) { return southExit; } if (direction.equals ("west")) { return westExit; } return null; return null;} Chapter 7: zuul-bad Chapter 7: zuul-better 

21 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Chapter 7: zuul-bad  Make fields in Room private and provide accessor methods to get them (e.g. getExit in Code 7.4). Make fields in Room private and provide accessor methods to get them (e.g. getExit in Code 7.4). In Game, can no longer reference directly the exit fields (all Room s) of Room. In Game, can no longer reference directly the exit fields (all Room s) of Room. In Game. printLocationInfo (which does so reference), we could just change it to use the accessor method, rather than the field. In Game. printLocationInfo (which does so reference), we could just change it to use the accessor method, rather than the field. However, it’s neater to invoke a (new) method of Room to get the exit information it needs to print (Code 7.6, p218). Each Room object has that information, so it is really its responsibility. However, it’s neater to invoke a (new) method of Room to get the exit information it needs to print (Code 7.6, p218). Each Room object has that information, so it is really its responsibility. For Game. goRoom (which also does so reference), thirteen lines of code collapse to one (see p214). For Game. goRoom (which also does so reference), thirteen lines of code collapse to one (see p214). Chapter 7: zuul-better It maps a String (direction) into an exit Room. It maps a String (direction) into an exit Room. But that’s just the function of a: But that’s just the function of a: So, replace the four exit fields with one of the above (private of course) – Code 7.5. Now, we can have as many exits as we like. So, replace the four exit fields with one of the above (private of course) – Code 7.5. Now, we can have as many exits as we like. Finally, replace the setExits method (which burns the message “four exits” into its definition) with a single setExit method (which we can invoke for as many exits as we like). Finally, replace the setExits method (which burns the message “four exits” into its definition) with a single setExit method (which we can invoke for as many exits as we like). Now, Room is independent of its number of exits. Now, Room is independent of its number of exits. HashMap HashMap

22 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling World of Zuul Chapter 7: zuul-bad Chapter 7: zuul-better MORAL: class diagrams are not enough to tell whether the design is good.

23 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Responsibility-Driven Design Where should we add new fields and new methods (and to which class)? Where should we add new fields and new methods (and to which class)? The class that holds the data (fields) processes (methods) the data. The class that holds the data (fields) processes (methods) the data. Responsibility-driven design leads to low coupling. Responsibility-driven design leads to low coupling. 23

24 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Localising Change One aim of reducing coupling and responsibility-driven design is to localise change. One aim of reducing coupling and responsibility-driven design is to localise change. When a change is needed, as few classes as possible should be affected. When a change is needed, as few classes as possible should be affected. Improve maintainability … make change easier. 24

25 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Think Ahead When designing a class, think what changes are likely to be made in the future. When designing a class, think what changes are likely to be made in the future. Aim to make those changes easy. Aim to make those changes easy. Improve maintainability … make change easier. 25

26 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Refactoring When classes are maintained, code usually needs to be added. When classes are maintained, code usually needs to be added. Lists of fields, lists of methods and the code inside methods tend to become longer. Lists of fields, lists of methods and the code inside methods tend to become longer. Every now and then, classes and methods should be refactored to maintain cohesion and low coupling. Every now and then, classes and methods should be refactored to maintain cohesion and low coupling. 26

27 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Refactoring and Testing When maintaining code, separate the refactoring from making other changes. When maintaining code, separate the refactoring from making other changes. Do the refactoring first, without adding to the functionality. Do the refactoring first, without adding to the functionality. Test before and after refactoring to ensure that nothing gets broken. Test before and after refactoring to ensure that nothing gets broken. e.g. zuul-bad to zuul-better. 27

28 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Design Questions Common questions: Common questions: How long should a class be?How long should a class be? How long should a method be?How long should a method be? Answered with regard to cohesion and coupling. 28

29 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Design Guidelines A method is too long if it does more then one logical task. 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. A class is too complex if it represents more than one logical entity. Note: these are guidelines … everything is still open to the designer. 29

30 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Enumerated Types A new language feature.A new language feature. Uses enum instead of class to introduce a new type name and a set of named constants of that type.Uses enum instead of class to introduce a new type name and a set of named constants of that type. This is a better (safer) alternative to a set of named static int constants.This is a better (safer) alternative to a set of named static int constants. For the World of Zuul, we shall use names for command words, rather than string literals (which will appear only in one place).For the World of Zuul, we shall use names for command words, rather than string literals (which will appear only in one place). 30 java.sun.com/docs/books/tutorial/java/javaOO/enum.html

31 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling A Basic Enumerated Type public enum CommandWord { // A value for each command word, // A value for each command word, // plus one for unrecognised commands. // plus one for unrecognised commands. GO, QUIT, HELP, UNKNOWN GO, QUIT, HELP, UNKNOWN} Enumerated objects are constructed implicitly. 31 Each name represents an object of the enumerated type, e.g. CommandWord.HELP. zuul-with-enum-v1

32 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Equivalent Class Type public class CommandWord {} 32 The constructor is declared private so that no CommandWord objects, other than the ones declared here, can be constructed. zuul-without-enum-v1 public class CommandWord { // A object for each command word, // A object for each command word, // plus one for unrecognised commands. // plus one for unrecognised commands. public final static Commandword GO = new CommandWord (); public final static Commandword GO = new CommandWord (); public final static Commandword QUIT = new CommandWord (); public final static Commandword QUIT = new CommandWord (); public final static Commandword HELP = new CommandWord (); public final static Commandword HELP = new CommandWord (); public final static Commandword UNKNOWN = new CommandWord (); public final static Commandword UNKNOWN = new CommandWord ();} public class CommandWord { private CommandWord () { // nothing to do } // nothing to do }}

33 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling public enum CommandWord { // A value for each command word, // A value for each command word, // plus one for unrecognised commands. // plus one for unrecognised commands. GO("go"), QUIT("quit"), HELP("help"), UNKNOWN("unknown"); } GO("go"), QUIT("quit"), HELP("help"), UNKNOWN("unknown"); } Another Enumerated Type public enum CommandWord { private final String commandString; private CommandWord (String commandString) { this.commandString = commandString; } private final String commandString; private CommandWord (String commandString) { this.commandString = commandString; }} 33 zuul-with-enum-v2 public enum CommandWord { public String toString () { return commandString; } }

34 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling public class CommandWord {} { // A object for each command word, // A object for each command word, // plus one for unrecognised commands. // plus one for unrecognised commands. public final static Commandword GO = new CommandWord ("go"); public final static Commandword GO = new CommandWord ("go"); public final static Commandword QUIT = new CommandWord ("quit"); public final static Commandword QUIT = new CommandWord ("quit"); public final static Commandword HELP = new CommandWord ("help"); public final static Commandword HELP = new CommandWord ("help"); public final static Commandword UNKNOWN = new CommandWord ("?"); public final static Commandword UNKNOWN = new CommandWord ("?"); } public class CommandWord { private final String commandString; private final String commandString;} Equivalent Class Type 34 public class CommandWord {... public String toString {returns the commandString}... public String toString {returns the commandString}} public class CommandWord {... public static CommandWord[] values {returns an array of above constants} }... public static CommandWord[] values {returns an array of above constants} } public class CommandWord {... private constructor {to construct the above constants}... private constructor {to construct the above constants}} zuul-without-enum-v2 Automatically provided by the enum

35 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling public class CommandWord { { // A object for each command word, // A object for each command word, // plus one for unrecognised commands. // plus one for unrecognised commands. public final static Commandword GO = new CommandWord ("go"); public final static Commandword GO = new CommandWord ("go"); public final static Commandword QUIT = new CommandWord ("quit"); public final static Commandword QUIT = new CommandWord ("quit"); public final static Commandword HELP = new CommandWord ("help"); public final static Commandword HELP = new CommandWord ("help"); public final static Commandword UNKNOWN = new CommandWord ("?"); public final static Commandword UNKNOWN = new CommandWord ("?"); public class CommandWord { private final String commandString; private CommandWord (String commandString) { this.commandString = commandString; }... private final String commandString; private CommandWord (String commandString) { this.commandString = commandString; }... Equivalent Class Type 35 zuul-without-enum-v2

36 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling public class CommandWord {... public final statics (GO, QUIT, HELP, UNKNOWN)... public final statics (GO, QUIT, HELP, UNKNOWN) } public class CommandWord { private final String commandString; private CommandWord (String commandString) { this.commandString = commandString; } private final String commandString; private CommandWord (String commandString) { this.commandString = commandString; } Equivalent Class Type 36 public class CommandWord { public String toString () { return commandString; } } public class CommandWord { public static CommandWord[] values () { return new CommandWord[] {GO, QUIT, HELP, UNKNOWN}; } } zuul-without-enum-v2 Automatically provided by the enum

37 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling See also … 37 zuul-with-enum-v1 zuul-with-enum-v2 zuul-without-enum-v1 zuul-without-enum-v2 zuul-without-enum-v3 zuul-without-enum-v4 projects\chapter07\projects\chapter07\courses\co320_ca13\projects-phwcourses\co320_ca13\projects-phw zuul-better

38 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Review Programs are continuously changed. Programs are continuously changed. It is important to anticipate change and make it as easy as possible. It is important to anticipate change and make it as easy as possible. Quality of code requires much more than just performing correctly! Quality of code requires much more than just performing correctly! Code must be understandable and maintainable. Code must be understandable and maintainable. 38

39 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Good quality code avoids duplication, displays high cohesion, low coupling. Good quality code avoids duplication, displays high cohesion, low coupling. Coding style (commenting, naming, layout, etc.) is also very important. Coding style (commenting, naming, layout, etc.) is also very important. There is a big difference in the amount of work required to maintain poorly structured and well structured code. There is a big difference in the amount of work required to maintain poorly structured and well structured code. In fact, unless it is well structured, the code is doomed … it will not be used for long. In fact, unless it is well structured, the code is doomed … it will not be used for long. Review 39


Download ppt "Design: Coupling and Cohesion How to write classes in a way that they are easily understandable, maintainable and reusable."

Similar presentations


Ads by Google