Preface

To solve a problem we usually think about it first generally, on abstraction level. We try to calculate resources, (money, e.g): we decompose the problem. In case of limitation the human may use some tricks: if we do not have enough wallpaper, we may not cover some hidden places: furniture, pictures, etc. can help. It means we try to organise the solution from the available resources according to a plan. These three elements of solving any problem, abstraction, decomposition and organisation together calls a paradigm. Previous programmers experience was based on functional paradigm.

Imagine that we are going to reach Trieste by car so we start to think how to do that. According to an old paradigm of programming we should have thought of the problem in terms of functions acting on data :

On abstraction level:

think of the problem in terms of a process that solves it, i.e. how to drive a care, how to collect necessary things, etc.

On decomposition level:

think how to break all this processing down into small manageable processing units, or functions; e.g. how to move a car from one point to another. We recognise driving in the town differs from driving in the highway. We think how to do stopping/starting the car etc. So we create functions;

On organisation level:

set up our functions so they call each other according to the rules. We set up sequences of function calls, passing different arguments to the functions, etc.

This is the clue: previous approaches to programming tend to separate data from the methods used to manipulate that data, or at least don't strongly encourage them to be considered in concert. This is not typical way of thinking: we have to define a set of data structures and then define set of functions acting upon these data structures.

In a real situation we think first about the way in general, and only having chosen the way we start to think how to get through the traffic in each of the cities and villages along the way. Then we think about details, where is the best place to stop for eating, sleeping etc, and after that we may think how to arrange the scheduler for this journey, to be in an particular restaurant at a particular time. This is an example of object-oriented thinking: we think in terms of objects interacting:

On abstraction level

we think in terms of independent agents (objects) working together: the car, ourselves, things to take etc.;

On decomposition level

we define the kinds of objects on which to split the global task;

On organisation level

we create the appropriate number of objects of each kind.

.

So, an introductory description of OOP can be based on the following guideline:

The solution to the problem should resemble the problem, and observers of the solution should be able to recognise the problem without necessarily knowing about it in advance.

A good example of this guideline from the computing world is the use of OOP to develop a stack class from which stack objects can be instantiated. If a stack is implemented as a class, instantiated as an object, and documented appropriately, programmers familiar with stacks, queues, and other similar data structures will recognise it as a stack without other prior knowledge.