Previous Chapter
| Previous Chapter |
Main Menu | Next Section |
Section I : The Object-Oriented Paradigm
In the last chapter we saw how a problem could be viewed as a
set of tasks to be accomplished. Complexity management then became
a process of decomposing the problem into tasks and subtasks until
one arrived at a set of tasks that were independent from each
other and easily grasped. Such tasks are, at least in theory,
easy to analyze, design and code.
For many years this process of functional decomposition was the
main tool programmers used to handle complexity. It made a certain
amount of practical sense because, as we noted in chapter 3,
humans do often handle task complexity by decomposing tasks into
smaller tasks. More recently, however, a new approach for analyzing
a complex problem and designing a solution has emerged.
This new design methodology is based on the object-oriented
programming (OOP) paradigm (a paradigm is a pattern or way
of looking at things. The object-oriented paradigm says that
the world can be best analyzed by focusing not on the tasks, but
on the objects found in the world.
Back in chapter one we argued that Computer Science can be seen
as a science of modeling, a study of how to create computation models of some aspect of our experience, some part of our world. To create a computer model, we need to analyze and come to an understanding of what it is we want to model. Humans seem to have a natural ability to create models so perhaps it is worth studying how we humans analyze and describe (create a model of) the elements of our existence. Although humans do perform functional decomposition when faced with a task to accomplish, they are much more likely to look at the world itself in terms of the objects (things) they see in that world.
Consider the idea of a school. While there are all kinds of actions
that go on in a school, if you ask someone to describe what
a school is, they are more likely to start with the objects that
exist in a school: teachers, students, classrooms, tests, homework,
etc. than the activities. Of course, part of the process of describing
these objects includes stating what they do. It is not that actions
are ignored. They are simply not the first aspects to be observed
and commented on.
Proponents of the object-oriented paradigm argue that programming
problems can be best analyzed by focusing first on the objects
involved in a problem and only then on the functions performed
by and on those objects. It is not so much a matter of which approach
is better but simply of which comes first - the object analysis
or the task analysis. Indeed, we shall see that all the work we
did with functions in the last chapter will be very important
in our efforts in this chapter.
The idea then is that when a programmer is given a new problem,
the decomposition process that initially takes place is in terms
of the objects found in the problem. These objects can be classified
into different groupings called classes, and these classes
can then be analyzed to determine:
In this way, a specific object is an instance of
a class and has all the properties, actions, and relationships
determined for the class.
The notions of 'class', object (instance) and 'property', as found in the object oriented approach, are not new concepts. Humans have been decomposing/dividing the world up into object and classes for as long as they have been wondering about the world. One strong example of this is Biology, where the complexity of life around us has been studied extensively in terms of classifying life forms into various groups and subgroups. The basic group is the species. Using the object oriented terms of class and instance, a species can be seen as a class and an individual member of the species as an instance (or object) of the class. Thus, you as an individual are an instance of the species (class) Homo Sapiens. You therefore have the general properties and know how to perform the general actions known to any instance of the class Homo Sapiens.
The strength of this approach for the study of life is that a
biologist can focus on the commonalties found in all members of
a species, for example, Homo Sapiens, and not worry about the
idiosyncrasies of a particular instance of the species, as in
the unique characteristics of a particular human. Same for the
programmer - he or she can design a class by focusing on the common
properties and actions of the class. Later, all instances of the
class (objects belonging to the class) can take advantage of that
design.
The OOP paradigm applies this notion to a specific programming
task by trying to discover the objects involved in the programming
task, the classes into which those objects can be grouped, and
the relationships among classes. As part of this analysis the
OOP paradigm seeks to determine what are the common properties
(characteristics) of all instances of each class and what actions
the instances of each class are capable of. From this, one can
design the necessary classes.
The OOP paradigm goes one step further with its ideas of class
and object. The properties of an object belong to the object itself
and should not easily be changed by other objects. It is not that
the properties can't be changed but the change should be controlled.
From a programming perspective, the idea of 'controlled changes'
helps insure that variables in a program do not get changed except
when such a change is really desired by the programmer. Local
variables and parameter passing in functions were a first step
to ensure 'controlled change' and the object paradigm extends
this idea. Since your only experience with programming may be
what you have done so far with this text, this issue may not be
clear. If so, you need to trust that one way to support the production
of 'bug free' code is to control when values get changed.
In the OOP approach 'controlled change' is implemented through
encapsulation. What encapsulation means is that the properties
of an object, as defined in the class, are 'inside' the object
and cannot be easily accessed or changed by other objects. As we will see, to change encapsulated properties, one tells the object itself that the change should be made and the object handles the actual change. Later, we will see that encapsulation allows the internals of a class to be changed without requiring any changes in the ways the class is used in programs.
 Top of Section |
Main Menu | Next Section |