Object Oriented Programming: The Fundamentals
tl;dr; This is an article I wrote in the 1993 that summarized the fundamentals of object oriented programming.
The 1990s saw the rise of “object oriented programing”. I was an early enthusiast, especially after reading “Object Oriented Software Construction” by Bertrand Meyer. I championed the programming language Eiffel, and eventually I worked for a company that build financial software in Eiffel.
I wrote the article below for a trade paper, called “The Sun Observer” (no longer in existence) and later the article was reprinted in ACM SIGPLAN magazine. I tried to explain what object oriented programming is all about.
Let me know what you think!
---
OBJECT ORIENTED PROGRAMMING : THE FUNDAMENTALS
by Richie Bielak
September 1993
INTRODUCTION
Object oriented means good, just look in the computer press. Not just the computer press - even Business Week had a cover story on object oriented programming. Look at the marketing brochures. All of a sudden every software package is object oriented. Object oriented is in.
With all the hype it is not surprising that many are skeptical. Those who survived through the "structured" and "AI" eras, wonder whether the new rage represents a fundamental change or just a whim of fashion.
This article discusses object oriented technology, but also looks for the substance beyond the buzzwords. Behind the hype lies a fundamental change.
WHY A NEW APPROACH?
Software development is hard. The essential difficulty with software is its malleability - software is hard, because it is "soft". Software is hard, because it is abstract "thought stuff" not constrained by physical laws. For example, would an architect consider adding another elevator to the Empire State Building a reasonable change? Everyday programmers change software systems as radically.
Mind you, much progress have been made since the discipline of programming was invented. In the early sixties writing a compiler was a 100 man-year project, today it is an exercise in an intermediate computer science course.
Despite the progress the problem remains. As the hardware improves, our software systems become more ambitious and more difficult to build. Today's methods cannot keep up with the users' demands. Products are shoddy, over budget and late. This is the "software crisis".
Since the seventies, "structured programming" has been the preferred method for building software systems. This method has been used not only in coding, but also in analysis and design.
Structured programming is a "divide-and-conquer" method for solving a problem. The programmer divides the functions of a system into smaller pieces. If any of these are too large, they are divided further. Only when each piece is small the code to implement it is written. This movement from the general to the specific, from the whole problem to its smallest parts, is called the "top-down" approach.
Software developers have used structured analysis, design and programming with fair success. Yet the software crisis remains, exposing the shortcomings of this method.
In theory, with precise specifications in hand a programmer can apply structured methods to build a system. However, a direct consequence of using the top-down approach is that each component is specific to the system - it is a hand-crafted, custom-built part. But anything built from such parts is difficult to change. In particular a small change in the specifications can cause an upheaval in the entire system.
In practice, specifications change constantly - they are often vague, stated only verbally, or not stated at all but guessed. It is not surprising then that a method which pre-supposes a clear specification does not work well.
As such custom software components only fit into one system the programmer is forced to start each new project from scratch. Contrast this with an electronic engineer, who can choose from a catalogue of standard parts.
Finally, structured design forces a hierarchical, top-down structure on the system, with the "main" functions at the top. But, as observed by Bertrand Meyer, real systems have no "top". For example, what is the "top" of a spreadsheet program?
The conclusion is clear. Why do we need a new method? Because the current one does not work.
THE FUNDAMENTALS
What is an "object"? Very simply, an object is some data and code stuck together. Not just any code and data together makes a good object. The idea is to put together code and data that belong together, because they represent a thing related to the problem. The more concrete the thing the better. For example, in a spreadsheet program a cell on the screen is such an object.
A very important feature of an object is that some of its data or code can be hidden from other objects. This isolation of object's internal structure is called encapsulation. Things visible to other objects are the interface.
Encapsulation is good, as it limits the effects of change. The internal structure of the object can change drastically, yet if the interface remains fixed, other objects are not affected.
To talk about the internal structure of objects we have to introduce more terminology. The data pieces of an object are called the attributes and the code pieces - the routines - are the methods. Unfortunately there is no standard object-oriented terminology, and the jargon varies from language to language. For example, an "attribute" is also an "instance variable" and "calling a method" is also "sending a message to an object."
Objects are runtime entities. When a program is executing, there may be many objects of the same kind. In the case of a spreadsheet each cell would be represented by an object.
All the objects of the same kind belong to a single class. In fact, what is written when using an object-oriented programming language (OOPL), is not objects but classes (Not 100 percent true; there are OO languages that do not have classes). In other words, first you decide what attributes and methods an object of the new kind will contain, and then you create a class that describes all such objects.
For example, a CELL class in a spreadsheet may contain attributes to hold the current value of the cell, its coordinates, and its formula. The methods will most likely include a routine to compute the new value using the formula. Once the class is written, to create CELL objects elsewhere in the program you can write "now create an object of class CELL" - using the appropriate syntax, of course.
So far, a class looks a lot like a module in a conventional programming language (i.e. C, PASCAL or Modula-2). What sets classes apart from modules is inheritance.
Inheritance is the mechanism for creation of new classes by extending and adapting old classes. In addition to the attributes and methods contained in the new class, more attributes and methods can be inherited from other classes. Furthermore, any inherited method can be redefined to perform a task more suited to the new class.
To make the terminology more generic, the class from which one inherits is called the parent and the class which does the inheriting is called the child.
The beauty of inheritance is that it makes "programming by differences" possible. Rather than write each class from scratch, the programmer can adapt an existing class by changing only the parts that need to be different.
Inheritance gives the child class the methods and attributes of its parents. Therefore, methods applicable to objects of the parent class can also be used on objects of the child class. In other words, the same operation can be applied to different kinds of objects. In a programming language, operations on an object are represented by operations on a variable, so each variable must be able to represent many types of objects. This ability to have a variable refer to objects of different classes is called polymorphism.
Presence of polymorphism and method redefinition requires that OOPLs use dynamic binding. Dynamic binding means that the association between a method call and the code executed has to be done at runtime.
Why? A method is invoked by applying an operation to a variable. Because of polymorphism the variable can refer to objects of different classes at runtime. Because the method in question can be redefined in some of these classes, the original call will result in execution of different code at different points in time.
Now that you have an idea what objects, classes, inheritance, polymorphism and dynamic binding are, we can consider this question: What is a program?
An object-oriented program is a collection of objects calling each other's methods to compute the answer. Usually one object is selected as the place where execution starts, but this choice is arbitrary. In principle execution can start in any object - there is no main line.
SUMMARY
The introduction of objects, classes, inheritance, polymorphism and dynamic binding into programming represents an attempt to solve some of the most difficult problems plaguing software development.
Classes and objects could become the equivalent of interchangeable, standard components. Writing a program would consist of selecting parts from a catalog and snapping them together. Think how quality of software would improve if it could be built from standard parts that have already been tested in many systems.
Inheritance and dynamic binding allow us to customize existing parts, in case they don't fit into a particular system exactly. But even with customization, only the code for new features needs to be written. When programmers write less code, there is less chance for errors, and the task takes less time.
That's why there is so much excitement surrounding object oriented technology - the object oriented method attacks the problems at the heart of the software crisis.
---