This page hosted by Get your own Free Home Page

Important Concepts of Object Orientation.

This section is a brief presentation of the most important concepts behind the idea of object-orientation. No matter how long are the texts, each of the topics would demand much more space to present correctly than what's available here. So the idea here is to present an overview and point to more complete references.

Object-Oriented Paradigm

Here we present the idea of object-orientation (OO) as a new form of thinking the program development. That means to present the main OO concepts and techniques.

What's a paradigm?

The word paradigm means a patterns, a model, and its most famous previous use was in grammar. But in the 60's, Thomas Kuhn, a philosopher of science proposed that science evolution is done by conceptual frames, called paradigms: during the vigence of a time frame, every scientist conceives his particular science based in certain concepts. Paradigms are not eternal and can be abandoned: the change of from a paradigm to another is called a paradigm shift.

A classical example of paradigms and of paradigm shift is given by mechanics. During the Newtonian paradigm, speed was conceived as having no limits and the mass of a body was supposed not to change with a change of the speed of the body. Then there was a paradigm shift and that model of thought was abandoned: the relativistic, or Einstenian, mechanics became the new model of thought in mechanics. In relativistic mechanics, the speed of a body can't be higher than the light speed, and a body mass grows with the increase of its speed.

In programming, the word paradigm shift is used to mean the change in the way the programmers community conceives and creates programs. It is often said that structured programming (SP) was a paradigm most programmers used till the beginning of the 80's. In SP, the emphasis is in functions --- or fragments of code, subroutines etc. --- and in the top-down decomposition of a program. Then in the end of the 80's and the beginning of the 90's, there was a paradigm shift and programmers begun to thing of programs in terms of objects, aggregates of functions and data (see What's in an object below). Then the bottom-up approach became important as lots of libraries were available and people were interested in using them (see What's reuse below).

Ideally, in a paradigm shift, the new paradigm replaces completely the old one. That was what happened in the transition between the Aristotelic mechanics --- all qualitative, numberless --- and Newtonian mechanics --- in certain ways a branch of analytical geometry.

However, that didn't happen in the transition from Newtonian and Relativistic mechanics: there are plenty of people using Newtonian mechanics today, and indeed some people will never have to learn Relativistic mechanics. Only people that deal with speeds close to the light's speed and huge distances are forced to learn it.

Since Newtonian mechanics is far simpler and more intuitive than Relativistic mechanics, people tend to use Relativity only when they're really forced to do it. So mechanic theories are more like tools: they use it when there's a problem that need it, much like we use a hammer to fix a nail, and a knife to cut something. In the same way a scientist will use Newtonian mechanics for situations closer to day to day experience and Relativistica mechanics to speeds close to the the light and astronomical distances.

The same happens with structured programming and object-oriented programming: they must also be seen as tools. Some problems are are better solved with SP techniques, while others are better solved by OOP. In When to use Objects the two types of situations are outlined.

What's in an object?

From a programming point of view, there has been lots of answers to this question. A very interesting one is in http://www.holub.com/goodies/what_is_an_object.html, by Allen Holub. Here will try a different approach: instead of a strictly technical point of view, we'll stress the conceptual side of things.

In object-oriented programming, an object is more than just data, more than just a couple of functions. Following the example of Bertrand Meyer, let's consider a common radio. It has a state and some means to alter and to consult this state. It state is, of course, the radio station it is dialed in, its sound volume and sintony. It has buttons to alter any of these dimensions of state, and usually a normal radio has some form of displaying the radio station frequency and sometimes a display of sound volume.

Usually, a normal radio has also a way to turn it on and off, often the same button, sometimes the volume button.

Now it is necessary to translate the radio elements to an object-oriented nomenclature. Since OOP isn't exclusive of radios, the translation of radio elements to more general ones is a means to see how OOP can be used to solve other problems. Table 1 below shows a mapping between the simple radio elements and the more general OOP terms.

Table 1: Radio Elements x OOP terms
Radio	OOP
On/Off	Constructor/Destructor
Display elements	Accessors
Volume and sintony dials	Transformer
Station frequency, sound volume and sintony	State

The on and off functions of a radio are named constructor and destructor because they are used to make the radio "come alive" and to make it inactive. Of course, the if you press the off button, or in general turn off the radio, it won't disappear, but will cease any activity that it is originally intended to have. In the same sense, a destructor won't cause the program line where the object was defined to disappear, but the corresponding variable won't be useful for doing any radio simulation: if you want the variable to be useful again, we'll have to call the constructor first.

Where are the objects?

That's a very delicate question in the context of object-orientation. In other words, it can be understood as "how can we conceive classes and objects, given an application domain?" Bertrand Meyer, following his polemist tendency, wrote in 1988: "the objects are just there for the picking!"

He meant to say that to conceive classes all we should do is to mirror the objects in the application domain. That is, if we are going to create an application to deal with accounts payable, a good candidate for a class is simply the account. If we are going to create a GUI (Graphical User Interface), with windows and buttons, then windows and buttons are good candidates to being classes. So, in the accounts payable application there would be an ACCOUNT, and in the application with GUI there would be classes WINDOW and BUTTON. And as much instances of the class --- or objects --- as needed to solve the problem.

That may sound a good idea to some of us, but this is not what authors Coad and Yourdon think. In their book Object-Oriented Analysis, they say about Meyer's idea: "Nuts!"

Such a strong word is very rare in the literature about object-orientation, and it surprised me then as much as it surprises you now. Coad and Yourdon state that the conception of classes in an application should be the result of a careful process of object-oriented analysis and design.

Ferocious debates like these are typical of the initial phases of all fields of technique and science. As more experiences are gathered, people tend to converge at intermediary positions and to forget the extremism of their own initial ideas.

An intermediary position can be that the conception of classes should be neither a faithful mirroring of the application domain, nor its complete neglect. Certainly, most of the object-orientation appeal lies in the possibility of mimicking some application domain behaviors in the software architecture level. However, an application is an application is an application: the purpose of an application is not to mimick faithfully the application domain, but to reproduce some of the most useful behaviors of the problem. Not all behaviors, not even all useful behaviors The development of an application usually is a negotiation between user and developer: some features are not implemented due to time or computer limitations, while other ones are added since their cost is small, since they're closer to computer nature, or to the software tools used to implement the application.

The fact is that the software development process is not done in the application domain world, but in another world: the world of the computer and the software tools (programming languages, compilers, libraries etc.) used to develop the application. An accounts payable is an application that will help solve accounts payable problem, not a form of accounts payable. Even if such an application is created by an accountist, it is still some form of software development, not a form of accounting practices. The world of software development has its own laws, that must be followed if we want that the software being developed be a good one.

So, going back to the question " how can we conceive classes and objects, given an application domain?", a good idea seems to try to dive deeply into the application domain in the first steps of the software development process, and try to capture as much of the application domain as we can. Then sit back and try to fit this application domain's conceptual architecture into a good software's architecture.

What's reuse?

In very few words, without any attempt of being academic, reuse can be defined as to use again, withouth any alteration, a piece of software already written. So, when you call printf() in a C program, you're doing some form of reuse. Of course, printf(), no matter how useful it is, is just a minimal, basic piece of software: it only writes a string to stdout, usually the computer screen.

An application programmer that creates an accounts payable software will receive only this minimal help from it. For this programmer, a piece of software more directly related to the accounts payble problem would be more useful. For instance, some software library that had functions to do the most common problems of accounts payable processing.

Since that library would "know" more about the problem of accounts payable, some say the library is more intelligent. The extreme limit of this would be a monolithic function, say AccountsPayable(), that would care about all and every aspect of the problem. So, your C++ program would be only:

int main            ( int argc, char** argv);
int AccountsPayable ( int argc, char** argv );

int main ( int argc, char** argv)
{
        return (AccountsPayable (int argc, char** argv));
}

Very good, isn't it? An application programmer would have only to write a few lines of code and everything would be done.

Very good, but very limited, for no matter how configurable AccountsPayable() can be command line parameters or setup files, it will have a limited flexibility. Even with configuration parameters, only a limited number of forms of doing accounts payable will be possible through AccountsPayable(): there's a strong possibility that some particular form is missing, even if it is minor one.

However, when we develop a specific application in source, it is usually because the existing applications in compiled form don't do what we want, and so you need maximum flexibility, and that can't be achieved with a solution as monolithic as this one. And the single function approach is as flexible as a closed application. This is the expression of a programming saying:

the more intelligent a programming piece of software, the less flexible it is.

In this application, if we need to change something in AccountsPayable(), that couldn't be changed by its parameters, we'll have to change AccountsPayable(), source code. In that case, of course, we won't be reusing it. A better idea is to have pieces of code not as minimal as printf(), but not as maximal as our AccountsPayable(). That relative size is called granularity: the smaller a piece of code, the lower is its granularity; and vice-versa, the larger a piece of code, the higher its granularity.

The golden goal of reuse is to maximize reuse without minimizing flexibility. Unfortunately, with any reuse we lose some flexibility: maybe a menu can't be changed, maybe some file format will not contain the every information we we want etc. But then we'll save a great deal of programming time, as some features of application programming will be already implemented. This balance is very important, as it limits te usefulness of the reused elements. If the package can't do, or what's worse, it won't allow us to do, something we consider very important, or if it does it too slowly, then it will be useless for us, at least for a particular application.

If that's the case, we'll have to find another package to reuse. Or maybe to develop our own package, using elements like printf(), that have minimal granularity, but maximal flexibility.

What OOP has to say about reuse?

OOP can enhance reuse through two key ideas: encapsulation and the open-closed principle.

The idea of encapsulation is that the data (state) of the object we try to reuse will be isolated from other parts of our software. Since the objects to reuse are insulated from the exterior, we can use them as small building blocks of our software, and we can be sure that unexpected side effects will be minimized.

The word module is the programming name for such building blocks. Programing done with the use of modules is called modular programming, and the first forms of modular programming predate OOP. For instance, languages as C can do a good job at modular programming. However, OOP and the object-oriented programming languages (OOPL) express more clearly the module concept. Sometimes, when using a modular language without object-oriented features, it is not so easy to see during the creation of a module what is to share and what to isolate from other modules.

The hard to understand FORTRAN IV programs and their evil COMMON blocks that I had to painfully debug are an eloquent witness of this. (Click here for a brief note on the FORTRAN IV programming language and its COMMON blocks.)

FORTRAN IV and its `COMMON` blocks

In FORTRAN IV the program structure was a bit limited. If you wanted to share a variable between modules, you'd have to
declare a COMMON block, where that variable would be declared. The problem was that a COMMON block actually shared bytes, not variables. That means it would happily let you access a double variable like two integer variables, without any regard to their names.
When you used several variables in the same COMMON block, any minimal error in typing would generate lots of problems. That problem was solved with theINCLUDEdirective, that would introduce the same file everywhere a COMMON block was needed.
However, it was not standard, and each compiler had its own version of INCLUDE. Or maybe no version at all...

When to use objects?

Object Technologies

The term object technologies (OT) was created to encompass several related technlogies, like OOP (object-oriented programming), OOD (object-oriented design) and OOA (object-oriented analysis). And, of course, to save an O, since it is just OT, not OOT.

The idea of an encompassing term is possible and sensible since these types of technologies are closely related. In very gross terms, one can say they differ only in the level of detail they approach the problem of software development. One can say OOA is done in the macroscopic level, without caring too much with the implementation details, and that OOP is done in the microscopic level, not only close to the implementation: it is the implementation technique. OOD is the gateway between the two: we can say it is done in the mesoscopic level.

That similarity between the three levels of object-oriented software development seems to be obvious but it is not: actually it is due the the fact that the notion of object is a unifying concept. Previous methods, like structured analysis (SA), design (SD) and programming (SP). To know a lot about SP wouldn't help very much in learning SA or SD.

So, the idea of object is just one more Columbus' egg: it looks very easy, and even very obvious, when we see it done. However, to get there was difficult and non-obvious. Like the discovery of the American continent by Cristopher Columbus.

To present the Object Technologies (OT), we'll use an analogy with the several stages of a building construction. The idea of a building isn't casual: if all we're going to do is to repair broken tiles in the kitchen, only masons would be necessary. In the same way, in a very small application, no analysis or design would be strictly necessary.

Object-Oriented Analysis

If we insist with the construction analogy, we can say that Object-Oriented Analysis (OOA) is analogous to a first phase of specification of the building, when initially architect and client talk in non-technical way about the building. During this series of interviews, the technical knowledge and experience of the architect will help the client think of every aspect of the building. The architect will hear what the client has to say about the building, as a means to inspire the creation of the general terms of the building. Even in these general terms, the architect will be able to help the user think about the building project, informing why some ideas must be rejected because they're unfeasible, suggesting more pragmatical or cheap alternatives, and will change his or her points of view due to better client arguments.

In terms of software development, this phase tries to arrive at an specification, that informs what characteristics the building should have in terms of architectural style, number of floors, and of course, budget available and expected deadline.

When this specification phase is done, the architect goes back to the office to detail the project a little more. Then he gets back to the client, for the aprovation of the building plans. The project is eventually aproved, after some minor modifications.

Then the architect details the project a little more, this time to ask a civil engineer to design the building physical structure.

The dialog between architect and engineer will be much more technical than the dialog had between architect and client. And a seasoned architect will actually conceive the building with an eye in its physical structure, to make easier the engineer's work.

When the engineer begins working in the project, it becomes more concrete and detailed. That's a consequence of the engineer's work: not only to conceive in abstract terms, but to determine the physical ways of making the project feasible.

In the software side of our metaphor, there is also a thinking in general terms, and indeed people talk about architectures; of course, software architectures. It means how the larger software units will be related to each other. However, the person that conceives a software architecture isn't usually called an architect, but an analyst. The idea here is that a software analyst is a person that understands a system that already works outside the software world. If there's not an existing system, people usually try to create in software an ideal system, respecting of course the limits of time and budget available for the software development.

In any case, the systems analyst must try to understand how the real or ideal system works, and this is done by breaking the system in its larger unities, and understanding the relationships they have to each other. The analysis phase then is brought to a finer level, and the analyst asks more detailed questions to the user. This process is repeated till the software analyst has a clear enough picture of the system. Then begins a synthesis phase, when the analyst will propose to the client his understanding of system. The analyst will present a new system, equivalent to the first one in general terms, but conceived with a view for software implementation.

For instance, if in some part of the original system a routine supposes the intelligence or creativity of a human being, then in the new system the software analyst should substitute it for another, simpler routine, that even a computer is able to execute.

That proposal of a software system will documented in texts, diagrams, and even program fragments called a prototype, that will have only some screens, and no heavy code behind them. It i as if a prototype was a movie scenario, in which houses are representated by their façades only. Usually, in this step the client has the equivalent of a croquis in architecture, and he's able to think more about the project. So, the analogy of software development with a building construction becomes stronger, and here as well as there, the user is able to discuss with the software analyst the details of what he expects the software to be. Here, as well as there, the experience of the software analyst will help the client think about every aspect of the software. The software analyst will hear what the client has to say about the building, as a means to inspire the general terms of the software. Even in these general terms, the software analyst will be able to help the client think about the software project, informing why some ideas must be rejected because they're unfeasible, suggesting more pragmatic or cheap alternatives, and will change his or her points of view if the client is able to present better arguments.

When they finally discuss all details of the software project in these general terms, the software analyst goes back to the office and prepares a formal proposal. This proposal will be very detailed and will contain a formal statemente about the software purposes, called a software specification, or just a specification. Besides the specification, this proposal will inform about the software deadlines and, of course, its cost.

That specification is commented by client and analyst, but mostly in terms that imply in cost and deadline: the technical side should be already stable. Usually, the software analyst will present several alternatives, and the client will chose between them.

The larger unities of the system will be translated as clases and objects, and the software analyst will be able to enrich the client specification with enough information that will ease the software designer work. For instance, when in the specification there's something like "the dept. X delivers information i to dept. Y", it will be translated as something like "the object X, of class Dept, will write the information i in database d, so that the it can be read by object Y, also of class Dept."

It is important to note in a building construction, sometimes the architect can forget about the engineering conveniences when creating the building form, in the software development, the systems analyst conducts all of the analysis in the light of a computer implementation. It is not that the analyst will also conduct the implementation together with the analysis, and it is not that he will talk to the client in very detailed terms of a computer program. No, the talks between client and analyst will be done in generic, non-techical terms. However, the analyst shouldn't forget in any moment, that the program will eventually be run in a computer system that is -- we all know it -- not very bright or creative.

So, the analyst role will be conducted with an eye towards making easier the software implementation, remembering the software will be run in a computer system, as well as making the implementation easier for the techniques the software designer will use.

Object-Oriented Design

Object-Oriented Programming

Back to page Free C++ Help.

Back to page On the C++ Programming Language.

Back to main page.

Thank you for visiting my pages.

These pages are under permanent construction.

Acknowledgements:

Background Patterns by J. Boersma.
Timothy Nall, who believes that C++ Doesn't Really Exist, reviewed the text of these pages.
I thank him any paragraph that is correctly written. As I hadn't followed all his suggestions, any error is my own fault.
Prof. Nall is also the author of a very interesting and informative site named The ELT Two Cents Café, dedicated to teaching English as a foreign language.

You can reach me by e-mail at: HFernandes@GeoCities.Com

These pages were accessed times since 24Sept 1998.

Last altered: Wed Sep 16 12:26:20 GMT-3:00 1998