January 2011 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material January 2011 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
This section discusses the nature of classes and objects. We begin with the philosophical background of classification and move onto descriptions of objects and classes that will be useful for software and system design.
The idea of classification is not a new one; philosophers have been studying the concept for at least two thousand years. We classify things all the time: we classify people by gender or by age; we classify motor vehicles by size, passenger capacity, and so on; we classify businesses into publicly and privately owned entities, amongst others. When we classify something we are saying that it has properties in common with others of its type. The idea is, at heart, a simple one. We assume that if we know something about the class, then that fact is true of all the members of the class as well. In writing a computer program that manipulates, say, customers' bank accounts, we need to be concerned first of all with the things that all bank accounts will have in common. We do not want to be concerned with individual customers unless there is something about them that is different to the class as a whole. This is a profoundly important and simplifying principle.
By being members of a class it is assumed that an object shares the general properties of the class. For example, all members of the class “human being” have certain properties in common; although there are a great many different human beings in the world, they are sufficiently similar that there should be no difficulty distinguishing between any human being and, for example, a cheese sandwich.
In object-oriented design, we classify all the objects that a system should know about. That is, we specifying classes that collectively describe all the behaviour of the system. Although we speak of object-oriented design, we are mostly interested in classes, rather than individual objects. Class modelling is the process of assigning classes, and describing their inter-relationships.
Class modelling works in software design because it allows complex systems to be described in such a way that the complexity becomes manageable. And all interesting (and most useful) software systems will be complex.
The “things” that a software system will process, recognise and serve are, by definition, objects. Users of the system, keyboards, screens, bank accounts, stock items, printouts, and so on, are all objects. By classifying these objects, that is, by creating and managing classes, the designers of the system impose some control on the complexity of the system. Although a complex system may manage many millions of objects, it will frequently manage orders of magnitude fewer classes, perhaps fewer than one hundred.
For the purposes of object-oriented modelling, an object can be defined as follows:
An object is a self-contained entity with well-defined, recognisable properties (attributes) and behaviour (operations). It can interact with other objects.
This leads to the following definition of a class:
A class embodies the properties and behaviour that a collection of objects have in common.
Having presented this philosophical discussion, you may be expecting classes themselves to be philosophical. In fact, they are usually not. Suppose we are designing a system to manage the work of a lending library. Some of the classes that will need to be considered are:
Book
Member
Reader
Borrower
Loan
Fine
Barcode
Return date
Of course, on more detailed inspection these may turn out to be inappropriate, and no doubt many other classes will have to be considered, but these initial ideas are appropriate classes because:
they are self-contained with well-defined behaviour and properties
each will have some instances (objects) that have a great deal in common
it is obvious that each has an important role to play in the system
A further key point is that some classes may in fact have sub-classes. For example, “Reader” and “Borrower” may in fact be types of “Member”.
Here are some concepts to consider when thinking about classes and objects:
In English we use the words “is a” to mean several different things. For example, in “Rover is a dog” we are saying that Rover is an instance of class dog. When we say “A dog is a mammal” we are saying that “dog” is a sub-classes of “mammal”, that is, all members of class dog share properties with members of class mammal. Therefore, in describing the relationship between classes and objects, you should take some trouble to use unambiguous terms like “is an instance of” and “is a subclass of”.
A class may have any number of instances, including one and zero. Classes can be defined that have zero members in practice and in principle. Student are often particularly reluctant to use classes that have only one instance. The “Internet”, for example, is the one and only instance of class “Internet”. Again, this may seem odd, but class modelling is about classes, not individuals.