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 ...
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
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:
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.
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
A secretary is an employee. And an employee is a person.
In this case, the is-a relationship is represented by subclasses, so that
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
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.
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
Wim Ahlers and Simon White