OO Design

From Ch 18 in booklet: steps:

1. study the specification and clarify it if necessary

2. derive objects and methods from the specification, so that the design acts as a model of the application. The verbs are methods and the nouns are objects.

3. generalize the objects into classes

4. check for reuse of library classes and other existing classes, using composition and inheritance as appropriate. “Is-a" and "has-a” analysis help check out whether inheritance or composition is appropriate. There are techniques to help in finding the relationship between classes.

5. use guidelines to refine a design

Find objects and methods

Question

Analyze the relationships between the following groups of classes (are they is-a or has-a):

1. house, door, roof, dwelling
2. person, man, woman
3. car, piston, gearbox, engine
4. triangle, rectangle, pentagon, line, polygon, point.

Relationship between classes, and coding:

is-a - Java code involves inheritance - extends.

has-a or consists-of - code involves new

Some Guidelines for class design

Use of the design approach that we have described is not guaranteed to lead to the perfect design. It is always worthwhile checking the design of each class against the following guidelines.

Keep data private
Variables should always be declared as private (or sometimes protected), but never as public. This maintains data hiding, one of the central principles of OOP. If data needs to be accessed or changed, do it via methods provided as part of the class.

Initialize the data
Although Java automatically initializes instance variables (but not local variables) to particular values, it is good practice to initialize them explicitly, either within the data declaration itself or by means of a constructor method.

Avoid large classes
If a class is more than 2 pages of text, it is a candidate for consideration for division into 2 or smaller classes. But this should only be done if there are clearly obvious classes to be formed from the large one. It is counter-productive to split an elegant cohesive class into contrived and ugly classes.

Make the class and method names meaningful
This will make them easy to use and more appealing for reuse.

Do not contrive inheritance
Using inheritance when it is not really appropriate can lead to contrived classes, which are more complex and perhaps longer than they need be.

When using inheritance, put shared items in the superclass

Use Refactoring
After an initial design has been created, or when some coding has been carried out, a study of the design may reveal that some simplification is possible. This may mean moving some methods to another class. It may mean creating new classes or amalgamating existing classes. This process is termed refactoring. We have already met a guideline for refactoring – place shared methods in the superclass.

Refactoring recognizes that it is often not possible to create an initial design that is ideal. Instead the design sometimes evolves towards an optimal structure. This may involve changing the design after coding is under way. Thus development is not carried out in distinct stages.

Case Study- Bank Account

Hee is a specification:
We need some software to manage a bank account. The account has a current balance (and a name, address, account number which we ignore for now.) We can pay in to the account, withdraw (if there is enough in the account), and find out the current balance.
We also have a 'gold account', which has an additional overdraft facity.

Do an OOD!!