您的位置:寻梦网首页编程乐园Java天地Core JavaJava Lecture Notes

Introduction

Content

Apply

Reflect

Extend

previous.gif
 (3087 bytes)

next.gif
 (2959 bytes)


Content Index

Content Page # 14

Object-oriented software development processes

In a short course like this module we cannot cover all the important ideas relevant to the subject of object-oriented software development. One idea that needs to be recognised but which we can safely ignore because of the straightforward software we will work with is that of the type of objects. This defines a set of objects that have the same interface, the same protocol of messages that they will respond to. (In Java you must be careful distinguish between interface that specify sets of messages and user interfaces.) We have no choice about the types involved in a situation, they are there waiting to be uncovered. Types are what we look for during analysis of what needs to be designed and coded. Classes are what we use when designing and coding object-oriented software. We have choice when selecting classes. Fortunately in many situations this is not an important distinction and types are implemented as classes, so we can just talk about classes.

A simple way of coming up with a list of potential classes is to consider the nouns that appear in any description of what is required of a system. Examining the verbs can help determine behaviour by suggesting the names of messages that instances of classes should receive. Almost always the list of classes you may come up with will be too large. You have to discard many potential classes. The ones you discard are those which have little or no behaviour. As a general rule you can discard classes whose only purpose is to hold some value for another class.

Usually, identifying classes like this is no more than identifying all the values of some attribute for another class. So in considering, for example, a class to model car registration, you might find descriptions of estate cars, hatchbacks, compact cars and three-wheeled cars and might decide that you need classes EstateCar, HatchBack, ThreeWheeler. If there is a need to record this information but it does not affect registration behaviour, then these classes are no more than a list of attribute values, one of which will be assigned to a Car object.

Although the system being constructed is rarely represented as one of its own objects, there may be a class with a single instance that plays a pivotal role organising how the other objects in the system work.

Back to top

basicline.gif (169 bytes)

RITSEC - Global Campus
Copyright ?1999 RITSEC- Middlesex University. All rights reserved.
webmaster@globalcampus.com.eg