If we think of a real-world object, such as a television (as in Figure 1.1, “The concept of a class - television example.”), it will have several features and properties:
We do not have to open the case to use it.
We have some controls to use it (buttons on the box, or a remote control).
We can still understand the concept of a television, even if it is connected to a DVD player.
It is complete when we purchase it, with any external requirements well documented.
The TV will not crash!
In many ways this compares very well to the notion of a class.
A class should:
Provide a well-defined interface - such as the remote control of the television.
Represent a clear concept - such as the concept of a television.
Be complete and well-documented - the television should have a plug and should have a manual that documents all features.
The code should be robust - it should not crash, like the television.
With a functional programming language (like C) we would have the component parts of the television scattered everywhere and we would be responsible for making them work correctly - there would be no case surrounding the electronic components.
Humans use class based descriptions all the time - what is a duck? (Think about this, we will discuss it soon.)
Classes allow us a way to represent complex structures within a programming language. They have two components:
States - (or data) are the values that the object has.
Methods - (or behaviour) are the ways in which the object can interact with its data, the actions.
The notation used in Figure 1.2, “The Television
class example.” on the right hand side is a Unified Modelling Language (UML)
representation of the Television
class for object-oriented modelling and programming.
An instance of a class is called an object.
© 2006
Dr. Derek Molloy
(DCU).