Software Objects and RealWorld Representations - Programming GPS and OpenStreetMap Applications with Java - page 9

1.3 Object-Oriented Programming

The video application served as a simple example to get a feel for object-
oriented programming (OOP) by referencing (or projecting) a real-world
object (or device) into a software environment. Getting used to thinking
in OOP terms, basically means recognizing scenarios as a communication
(or exchange) between objects, or things. It is important to understand,
that object-oriented programs mainly handle and use objects. The objects
themselves are usually designed separately (like devices) and often with
different intentions and for various environments.
After we used electronic devices to introduce the idea of independent
objects in a common programming environment, we now turn to a class of
objects that is a primary focus of this topic: a Car . What is a car? It is
not surprising that asking different people this simple question in different
situations results in different answers.
A Car can be a part of many scenarios:

ˆ A passenger of an airplane perceives a car as a tiny rectangle moving
on a line (road).

ˆ The passenger of a cab only has to know how to call one, get in, and
give the destination to the driver.

ˆ The driver of a car has access to more private \methods" to control
the car's behavior:
startEngine-shift-throttle-break-steer

ˆ The mechanic uses more specific methods to open the hood to fix
or tune the machine, which is usually done in the garage (develop)
before the car is being driven (deploy).

Nevertheless, one car is always the instance of one object (model), no
matter how you look at it or where you drive it. In OOP terminology, each
scenario (application) can require a different abstraction level. One idea of
programming with objects is to create objects with high abstraction (e.g.,
rectangle moving on a line) and actually use these simplified objects in
selected applications.
The object Car is an isolated entity. And just like real cars have been
improved in every aspect over decades, the object Car can be enriched
for every new application in which it is used. This style of programming
automatically leads to code reuse for all aspects of a car in one place. This
process of learning, testing, and reusing isolated objects makes OOP so
robust, even in unexpected situations.
In what follows, we develop objects and applications as independent
of each other as possible.

For example a very simple class Car can be