5. Objects overview
Before we can sensibly use an OOP, we need to understand some underlying object related concepts. We must know:
- What an object is.
- What a class is.
- What the relationship is between a class and an object.
- How objects communicate with each other by using messages.
What is an object?
An object is a bundle of related variables and functions that belong together, i.e. they are grouped into a single entity.
Software objects are often used to model real-world objects that are all around you. A computer is sometimes called The Universal Machine because it can be programmed to simulate any other machine. Objects are a large part of how this is achieved, because they can be designed to be just like their real-world counterparts, and to have the same virtual abilites and qualities as the real-world object physically has. Look around - you'll see plenty of real-world objects like your computer, your cellphone, the table the computer is sitting on, etc.
Real objects all have two characteristics:
- State - all the things that make them what they are, e.g. name, size, colour, alive, etc.
- Behavior - all the things that they can do, e.g. fall, break, stop, run, bark, etc.
Software objects are modeled on real objects in that they also have state and behavior. Java objects store their state in variables, and they implement their behavior through methods. A method is just a function (a subroutine of Java code) associated in some particular way with the object.
If you were writing a game that simulated driving a number of different kinds of racing cars, you might decide to simulate the cars with an Automobile object, and the actions of the driver through a Driver object. Objects also allow you to model abstract concepts. For example, an event can be modeled as an object to allow control of a user interface, where an event object would represent the user clicking a mouse button, or pressing a key on the keyboard. Here is a representation of a general software object:
Everything that the software object knows (state) and can do (behavior) is expressed by the variables and the methods within that object. A software object that modeled a real-world automobile would have variables that indicated the automobile's current state: speed 75 km/h, 4th gear, engine speed 1800 rpm, fuel in tank 39 litres. These variables are called instance variables because they will contain the state of a particular automobile object, and in object-oriented terminology a particular object is called an instance (of a class). The following figure shows an automobile modeled as a software object:
A software automobile would also have methods for braking, accelerating, starting the engine, stopping the engine, changing gear, adding fuel to the tank:
Note that the automobile doesn't have a method for simply changing it's speed because the speed is a function of a lot of factors, e.g. whether the brakes are on, how fast the engine is turning, what gear it's in, how steep the hill is, etc. Our automobile has instead a method for accelerating, i.e. changing the engine revolutions (a better name would be changeRPM). This a single method that allows both an increase and a decrease in engine r.p.m.; decreases are achieved by a negative argument for the method.
Actually, the table type representation of an object that you saw above, is not the best representation. In Java, an object's variables are screened - protected if you like - by the object's methods from any outside interference. We say that the variables are encapsulated by the methods. What this really means is that the methods must stand between the outside world and the variables, so that the state of the object cannot be manipulated in an unexpected or unauthorised way.
Unfortunately, this is not always practical and some objects may want to expose some variables and hide some methods. Java allows this when neccessary by having several access levels to the variables and methods of objects. The access level determines which other objects and classes are allowed to use the methods and change the state of an object.
There are two chief benefits to this system of encapsulation.
- Firstly, the source code for any object can be stored and maintained independently of the code for any other object. Also, objects can be passed around the system, i.e. you can give or lend your automobile to someone else, and it will still work.
- The object has a public interface which other objects must use to communicate with it. Private information and methods can be kept hidden from all other objects, which means that the values and methods can be modified at any time without affecting any other part of the code. You don't have to understand how the engine works in order to be able to drive an automobile.