cs1ch5sec1.htm
 
CHAPTER 5

Object-Oriented Design
 


Section I : The Object-Oriented Paradigm Section II: Class Analysis and Design Section III: CRC Cards Section IV: Classes in C++
Section V: Defining Classes Section VI: Using Class Declarations in a Program Section VII: Constructors Section VIII: Expanding the Idea of Classes


  


Table of Contents

Learning C++:
An Index of Entry Points


2. The

of C++

A reference document on the basic elements of C++.



3. The Patterns



Index!


 

 

 


Humans are much more likely to look at the world itself in terms of the objects (things) they see in that world.

 

 

 

 


Think of specific objects in your life. What class do they belong to?

 

 

 

 

 

 

 

 

 

 


Programs have too many bugs. We need to minimize the possibility that a change on one part of a program causes an unintended change in some other part of the program


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:

the properties held by objects of the class,
the actions objects of the class are capable of performing,
the relationshipsbetween classes.

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