Objects First With Java A Practical Introduction Using BlueJ

Designing object-oriented programs

How to write code in a way that is easily understandable, maintainable and reusable 2.0

Main concepts to be covered

• • Designing applications vs designing classes Improving the quality of the code 2

A problem description

The cinema booking system should store seat bookings for multiple theatres.

Each theatre has seats arranged in rows.

Customers can reserve seats and are given a row number and seat number.

They may request bookings of several adjoining seats.

Each booking is for a particular show (i.e., the screening of a given movie at a certain time).

Shows are at an assigned date and time, and scheduled in a theatre where they are screened.

The system stores the customers’ telephone number.

3

Nouns and verbs

• • The nouns in a description refer to ‘things’.

– Source of classes and objects.

The verbs refer to actions.

– Source of interactions between objects.

– Actions are behavior, and hence methods.

4

Nouns and verbs

Cinema booking system

Stores (seat bookings) Stores (telephone number)

Theatre

Has (seats)

Movie Time Date Customer

Reserves (seats) Is given (row number, seat number) Requests (seat booking)

Show

Is scheduled (in theatre)

Telephone number Seat booking Seat Seat number Row Row number

5

Using CRC cards

• • First described by Kent Beck and Ward Cunningham.

Each index cards records: – A class name.

– The class’s responsibilities.

– The class’s collaborators.

6

A CRC card

Class name Collaborators Responsibilities

7

A partial example

CinemaBookingSystem

Collaborators

Can find shows by Show title and day.

Stores collection of Collection shows.

Retrieves and displays show details.

...

8

Scenarios as analysis

• • • Scenarios serve to check the problem description is clear and complete.

Sufficient time should be taken over the analysis.

The analysis will lead into design.

– Spotting errors or omissions here will save considerable wasted effort later.

9

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

10

Example:

Maintainability of calculator program

• • Each module does not need to know implementation details of the other and they can be implemented separately Each module does not depend on the implementation details of the other and they can be implemented and replaced independently 11

Code quality

Two important concepts for quality of code: • • Coupling Cohesion 12

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.

13

Loose coupling

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

Thus: improves maintainability.

14

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.

15

High cohesion

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

16

Cohesion of methods

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

17

Cohesion of classes

• Classes should represent one single, well defined entity.

18

Code duplication

• • • Code duplication is an indicator of bad design, makes maintenance harder, can lead to introduction of errors during maintenance.

19

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.

20

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.

21

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.

22

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.

23

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.

24

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.

25

Design guidelines

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

26

Review

• • • • Programs are continuously changed.

It is important to make this change possible.

Quality of code requires much more than just correct performance at one time.

Code must be understandable and maintainable.

27

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.

28