Designing classes How to write classes in a

  • Slides: 46
Download presentation
Designing classes How to write classes in a way that they are easily understandable,

Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 3. 0

Main concepts to be covered • • Responsibility-driven design Coupling Cohesion Refactoring Objects First

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

Software changes • Software is not like a novel that is written once and

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). Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 3

Change or die • There are only two options for software: – Either it

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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 4

World of Zuul Objects First with Java - A Practical Introduction using Blue. J,

World of Zuul Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 5

World of Zuul (2) Objects First with Java - A Practical Introduction using Blue.

World of Zuul (2) Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 6

Code quality • Two important concepts for quality of code: – Coupling – Cohesion

Code quality • Two important concepts for quality of code: – Coupling – Cohesion Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 7

Coupling • Coupling refers to links between separate units of a program. • If

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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 8

Loose coupling • Loose coupling makes it possible to: – understand one class without

Loose coupling • Loose coupling makes it possible to: – understand one class without reading others; – change one class without affecting others. – Thus: improves maintainability. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 9

Cohesion • Cohesion refers to the number and diversity of tasks that a single

Cohesion • Cohesion refers to 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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 10

High cohesion • High cohesion makes it easier to: – understand what a class

High cohesion • High cohesion makes it easier to: – understand what a class or method does; – use descriptive names; – reuse classes or methods. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 11

Cohesion of methods • A method should be responsible for one and only one

Cohesion of methods • A method should be responsible for one and only one well defined task. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 12

Cohesion of classes • Classes should represent one single, well defined entity. Objects First

Cohesion of classes • Classes should represent one single, well defined entity. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 13

Code duplication • Code duplication – is an indicator of bad design, – makes

Code duplication • Code duplication – is an indicator of bad design, – makes maintenance harder, – can lead to introduction of errors during maintenance. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 14

Code duplication (2) Objects First with Java - A Practical Introduction using Blue. J,

Code duplication (2) Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 15

Making Extension • We want to add 2 new direction: – up – down

Making Extension • We want to add 2 new direction: – up – down • Which class or classes should be change? Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 16

Making Extension (2) • How does Exits information implemented? • Is the implementation efficient?

Making Extension (2) • How does Exits information implemented? • Is the implementation efficient? • How can improve it? • Encapsulation: – Hiding implementation information from view Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 17

Making Extension (3) • • Public or private? Using accessor method Loose the coupling

Making Extension (3) • • Public or private? Using accessor method Loose the coupling Public parts of a class are parts of the interface. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 18

Applying Encapsulation (1) private String description; private Room north. Exit; private Room south. Exit;

Applying Encapsulation (1) private String description; private Room north. Exit; private Room south. Exit; private Room east. Exit; private Room west. Exit; public Room get. Exit(String direction) { if(direction. equals("north")) return north. Exit; if(direction. equals("east")) return east. Exit; if(direction. equals("south")) return south. Exit; if(direction. equals("west")) return west. Exit; return null; } Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 19

Applying Encapsulation (2) Instead of writing next. Room = current. Room. east. Exit; We

Applying Encapsulation (2) Instead of writing next. Room = current. Room. east. Exit; We now write: next. Room = current. Room. get. Exit("east"); Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 20

Applying Encapsulation (3) Room next. Room = null; if(direction. equals("north")) next. Room = current.

Applying Encapsulation (3) Room next. Room = null; if(direction. equals("north")) next. Room = current. Room. get. Exit("north"); if(direction. equals("east")) next. Room = current. Room. get. Exit("east"); if(direction. equals("south")) next. Room = current. Room. get. Exit("south"); if(direction. equals("west")) next. Room = current. Room. get. Exit("west"); Room next. Room = current. Room. get. Exit(direction); Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 21

Changing Implementation (1) • Using Map for storing neighbors information. private Hash. Map<String, Room>

Changing Implementation (1) • Using Map for storing neighbors information. private Hash. Map<String, Room> exits; Write set. Exit and get. Exit. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 22

Changing Implementation (2) public void set. Exit(String direction, Room neighbor) { exits. put(direction, neighbor);

Changing Implementation (2) public void set. Exit(String direction, Room neighbor) { exits. put(direction, neighbor); } lab. set. Exits(outside, office, null); lab. set. Exit("north", outside); lab. set. Exit("east", office); Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 23

Responsibility-driven design • Question: where should we add a new method (which class)? •

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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 24

Responsibility-driven design (2) • Which class is responsible to make exits info? • Which

Responsibility-driven design (2) • Which class is responsible to make exits info? • Which class is responsible to make description of a room? Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 25

Applying RDD (1) public String get. Exit. String() { String exit. String = "Exits:

Applying RDD (1) public String get. Exit. String() { String exit. String = "Exits: "; if(north. Exit != null) exit. String += "north "; if(east. Exit != null) exit. String += "east "; if(south. Exit != null) exit. String += "south "; if(west. Exit != null) exit. String += "west "; return exit. String; } Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 26

Applying RDD (2) public String get. Exit. String() { String return. String = "Exits:

Applying RDD (2) public String get. Exit. String() { String return. String = "Exits: "; Set<String> keys = exits. key. Set(); for(String exit : keys) { return. String += " " + exit; } return. String; } Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 27

Further RDD to Room Class In Game Class: System. out. println("You are " +

Further RDD to Room Class In Game Class: System. out. println("You are " + current. Room. get. Description()); System. out. println(current. Room. get. Exit. String()); If later we add other items to Room, we must change the code above. Sloution: Adding new method that return full detail of the Room. (get. Long. Description) ^ 6. 12, 6. 13 Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 28

Localizing change • One aim of reducing coupling and responsibility-driven design is to localize

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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 29

Implicit coupling • One class is depends on internal information of another class. •

Implicit coupling • One class is depends on internal information of another class. • New command: look • Adding look to valid commands and implement it. • And now issuing the help command, new command does not list! Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 30

Implicit coupling (2) • Who must list the valid commands? Game Parser Command. Words

Implicit coupling (2) • Who must list the valid commands? Game Parser Command. Words • Zuul-better Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 31

Thinking ahead • When designing a class, we try to think what changes are

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. • For example adding GUI to Zuul … Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 32

Cohesion (again!) • Method cohesion – Print welcome • Class cohesion – Another extension

Cohesion (again!) • Method cohesion – Print welcome • Class cohesion – Another extension to zuul: • Adding item to game – Which class must describe the items? Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 33

Cohesion (2) • Cohesion for – Readability – Reuse • 7. 23~7. 26 (Stack)

Cohesion (2) • Cohesion for – Readability – Reuse • 7. 23~7. 26 (Stack) Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 34

Refactoring • When classes are maintained, often code is added. • Classes and methods

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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 35

Refactoring and testing • When refactoring code, separate the refactoring from making other changes.

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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 36

Refactoring and testing (2) • Adding item to game. • The player can carry

Refactoring and testing (2) • Adding item to game. • The player can carry some items. • The items and their weight must be keep somewhere. • We need a field to keep the maximum weight the player can carry. • Where should we add these data? Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 37

Design guidelines • Design hint: – Don’t put too much into a single method.

Design guidelines • Design hint: – Don’t put too much into a single method. – Don’t put everything into one class. • Common questions: – How long should a class be? – How long should a method be? • Can now be answered in terms of cohesion and coupling. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 38

Design guidelines (2) • A method is too long if it does more than

Design guidelines (2) • A method is too long if it does more than 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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 39

Enumerated Types • A language feature for finite set of values. • Uses enum

Enumerated Types • A language feature for finite set of values. • Uses enum instead of class to introduce a type name. • Simplest use is to define a set of significant names. – Alternative to static int constants. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 40

Enumerated Types (2) public enum Command. Word { // A value for each command

Enumerated Types (2) public enum Command. Word { // A value for each command word, // plus one for unrecognised commands. GO, QUIT, HELP, UNKNOWN; } • Each name represents an object of the enumerated type, e. g. Command. Word. HELP. • Enumerated objects are not created directly by the programmer. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 41

Enumerated Types (3) • Example: public enum Size { SMALL, MEDIUM, LARGE }; Typical

Enumerated Types (3) • Example: public enum Size { SMALL, MEDIUM, LARGE }; Typical use: Size image. Size = Size. MEDIUM; If (image. Size == Size. SMALL). . . • Safer than integer constants public static final int SMALL = 1; public static final int MEDIUM = 2; public static final int LARGE = 3; Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 42

Enumerated Types (extra!) • enum equivalent to class with fixed number of instances •

Enumerated Types (extra!) • enum equivalent to class with fixed number of instances • public class Size { private /* ! */ Size() { } public static final Size SMALL = new Size(); public static final Size MEDIUM = new Size(); public static final Size LARGE = new Size(); } • enum types are classes; can add methods, fields, constructors 43

Class Methods • Instance method • Class method • Static fields • Static methods

Class Methods • Instance method • Class method • Static fields • Static methods • pubic static void main(…) • Limitations of class methods • Math class Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 44

Review • Programs are continuously changed. • It is important to make this change

Review • 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. • the nonfunctional aspects of an application. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 45

Review • Good quality code avoids duplication, displays high cohesion, low coupling. • Coding

Review • 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. Objects First with Java - A Practical Introduction using Blue. J, © David J. Barnes, Michael Kölling 46