Recent Articles

What's Good About Clojure?

Clojure is a relatively new language to appear on the Java Virtual Machine (JVM), although it draws on very mature roots in the form of the LISP langu ...

Should You Care About Requirements Engineering?

Recently, I (Adil) was invited to participate in a one day seminar on the subject of Requirements Engineering. Whilst I have no direct experience of t ...

Tips for Setting Up Your First Business Website

To attract all potential customers to your business you need a presence on the web. The problem is that if you haven't set up a website before, you p ...

What's Good about LISP?

LISP is a general-purpose programming language and is the second-oldest programming language still in use, but how much do you know about it? Did you ...

Open Source Tools for Developers: Why They Matter

From a developer's point of view use of open-source tools has advantages beyond the obvious economic ones. With the open-source database MySQL in mind ...

Simulating Object-Orientation and the Procedural Mindset

Discuss this article >>>

Introduction

There's no doubt about it - object orientation is a modern programming paradigm that is both fashionable and respectable. But many programmers have grown up with procedural languages, and it can be very hard for procedural programmers to switch to the object-oriented (OO) mindset. There are plenty of books available that teach the concepts, but the best way of learning is through contact with an experienced OO developer.

What is Object Orientation?

Any introductory course on OO will start by saying that there are three main features that make a language object-oriented:

Encapsulation

Encapsulation is the ability to separate the information that is only needed internally in a class or component from the information that needs to be exposed to its external users. In effect, the internal information is "hidden" from a component's external users, thereby guaranteeing that external components cannot corrupt any of the data to which they need no direct access.

Inheritance

Inheritance is the ability to extend and enhance existing classes by adding new data or behavioural members to the extended subclasses. This mechanism enables you to reuse an abstract concept or behaviour and specialise it to a specific task without having to rewrite the whole solution from scratch.

Polymorphism

Polymorphism is the ability to process objects differently depending on their class. That means that as a programmer you can make a separation between a logical function and its implementation. A commonly cited example is to compute the area of a polygon. The concept of area is common to all polygons, whereas the implementation is different depending on the type. The idea is that you can call the same method on any polygon and at runtime the correct implementation of the method will be used to compute the result.

For the full "object-oriented experience" you need to use an object-oriented programming language. However, object based programming can be done in any programming language, including procedural COBOL. Object-based programming borrows the ideas of object-oriented programming and uses them in a non object-oriented context. As far as possible, the borrowed OO features are simulated in the procedural language. This may work well for some OO features and not so well for others, depending on the language. Therefore, object-based programming can be considered a hybrid between procedural programming and true object-orientation.

In fact, object-based programming is not as uncommon as you might imagine, as some popular contemporary languages do not implement all the ideas of object-orientation. For example, neither Perl nor Python allow you to hide the member variables of a class by making them private or protected, and therefore rely on the users of a class being trustworthy.

We now focus on the issue of polymorphism and show how it can be simulated in a language that is not object-oriented.

Simulating Polymorphism

In object-oriented programming, the term polymorphism is used to describe a variable that may refer to objects whose class is not known at compile time. The code responds to the class of the object at runtime and behaves appropriately. Polymorphism is an essential feature of any truly object-oriented language, but languages that are not object-oriented, like procedural COBOL, typically lack this feature. In this case, polymorphism can only be simulated.

To simulate polymorphism, the behaviour of a method needs to be sensitive to the objects that are passed as arguments. In other words, it needs to perform tests on those objects. This is the kind of thing that can be done in most procedural languages with a long CASE (or perhaps a long nested IF..THEN..ELSE) statement that states what action should be performed for each of the anticipated object types. If appropriate, the polymorphic method can delegate its task to a type-specific method once it has identified which one to invoke.

Note that excessive use of CASE statements can lead to programs that are difficult to read and contain complex logic that is costly to maintain. These undesirable effects can be mitigated by making a clear separation between the polymorphic implementation logic and the type-specific behaviour. This idea is illustrated in the following figure. Note that the construct that we have referred to as a 'CASE statement' in the text is actually called 'EVALUATE' in procedural COBOL.

The code fragments within the boxes are written in procedural COBOL (in this case also using the non-standard ENTRY statement). The variable CAobj refers to a data structure that contains some session controlling and other session-related information. The illustration represents the bonus calculation for the employees (Persons) of an imaginary company. Three person roles are described, namely: a CEO, a manager and a secretary. Based on their role type they all receive different bonuses.

A secretary is an employee. And an employee is a person.

In this case, the is-a relationship is represented by subclasses, so that Secretary is a sub class of Employee, which is a sub class of Person. (Secretary is indirectly also a sub class of Person). aPerson is an instance of class Person representing an employee with a specific role. It is the software representation of a real life unique person. E.g.: 'Mrs. Doe' is a Secretary and is an Employee and is aPerson. 'Mrs. Doe' is just one unique Person object, 'Ms. Johnson' is another unique Person object. 'Ms. Johnson' might have the role of a CEO, manager or another secretary.

Notice that all the methods mentioned in the figure above have exactly the same name and use exactly the same interface. Notice also that the CEO has no knowledge of other roles other than that these other roles exist (see IF...ELSE... statement in the figure above). Similarly, the manager and secretary role have no knowledge of any other roles.

The bonus calculation for each employee is guaranteed to be calculated correctly regardless of the Salary.bonus(CAobj, aPerson) method called.

Over time many different roles may appear and disappear again. However, during all this time these changes do not affect the existing code at all.

The only code affected is the code in the module with the physical load module name SALARY__. This delegating module contains only one main statement, namely the CASE (EVALUATE) statement. It is this module that knows, and needs to know, all the others. But this module is extremely simple to maintain because it is central, isolated and it only contains calls to other modules based on the role type (object class). The SALARY__ code does not contain business or any other logic.

It is an interesting progression to extract the association between the object types and the associated method call into an external data source, and implement our polymorphic method as two basic steps: First, a generic lookup to see which method to call, followed by an actual call to the named method. The association could even be stored in a database such that the class ID is used as a key to retrieve the physical method name. Then, as roles appear and disappear over time, we would update the behaviour of our polymorphic method simply by changing the entries in the database.

Conclusion

We have discussed some essential features for an object-oriented language, and argued that, to some extent, they can be simulated with simple constructs in a purely procedural language. As a demonstration, we showed how polymorphism can be simulated in procedural COBOL.

We stated that languages that contain some OO features but not others are often referred to as being object-based. In principle the analysis and design for an object based system can be the same as for an object oriented one; only the implementation is different.

For a fuller account of the project that led to this article, please see http://www.programmersheaven.com/2/Art_ObjBasedSystems

Discuss this article >>>

Wim Ahlers and Simon White