In the hotel system, each room is different and may have a different occupant. However all rooms are the same in that each has a room name and a rate, for example, and each may have an occupant. If something did not have a room name and a rate, it would not count as a hotel room. Thus we generally talk about objects in terms of general classifications. Instead of repeatedly saying that the objects representing rooms 201 and 302 have names, can be ensuite or not and have a rate, we define the general properties of the Room class. In object terms, we say that rooms 201 and 302 are both instances of the class Room. We define a class called Room, saying what properties it has. Then by saying that rooms 201 and 302 are both instances of Room, we automatically understand that each has all the properties of the class.
System designers do not want to have to specify each room individually because all the rooms share a similar structure and behaviour; these shared properties can be captured once rather than repeatedly. So it is necessary to capture what all the rooms have in common, rather than the particulars of each separate room. Designing and programming in an object-oriented language consists mostly of writing definitions of classes, rather than of individual objects. One of the main challenges is to identify the properties that must be represented for any system.
It is useful to have a notation more abstract than program code to help us think about classes. A class diagram is one of the UML techniques previously mentioned, and we will be using it for this purpose. In a class diagram, each class is represented by a box called a class icon, divided into three areas, called compartments. The top compartment contains the class name, and the bottom one all the operations that are defined for that class. The name and the list of operations are all that clients of the class need to know. However, to implement the class, designers also need to know the structure of the class, so the middle compartment contains all the variables that constitute the current representation of the class; such variables are called attributes.
Figure 6 shows two class definitions. These represent all possible employees and all possible user interface windows within a system, respectively. The left-hand diagram shows the common structure of the Employee objects, indicating which operations can be applied to an Employee object and which data an Employee object stores. Each Employee object has exactly the same set of operations, but obviously each instance of Employee will have its own data. The data for the employee Jack are distinct from the data for employee Jill.
The class Employee has the operations setAddress and getAddress, setName and getName, setDateOfBirth and age. Only the name, address and date of birth are stored, so determining an age will require some computation. The representation might be changed later to store the age explicitly, but that would not affect any of the object's clients, because they use only the public operations, which would not have changed.
What is the relationship between a class and an object?
A class is a generalisation of all its instances, saying what structure and operations they have in common. Objects are the instances of a class.