Object-oriented programming

By: Huff, Sid L., Business Quarterly, 00076996, Winter93, Vol. 58, Issue 2

A new method of building and maintaining computer software emerging. It promises substantial savings in time and money

Most everyone, from three-year-olds to Senior Executives, has at one time or another played with lego sets. Truly amazing structures can be assembled out of collections of simple, standardized pieces. Building complex structures out of simple pieces also characterizes many other, commercially useful activities such as the design of electronic circuits. Why can we not build software the same way -- by assembling collections of simple, reusable "pieces" of code? The concept of software reuse is not new, but it has met with almost no success until quite recently. Constantly reinventing the wheel has characterized most software development until now. A somewhat radical new method, different enough from the traditional approaches to programming to be termed a new paradigm, is emerging out of specialized software labs and into the pragmatic mainstream. It is called the "object-oriented" approach to software development. Reflecting its newness and somewhat controversial nature, object-oriented programming goes by the descriptive acronym OOP. It opens a door, which, over the long term, promises to lead adopting organizations out of today's low-productivity, maintenance-dominated, software crisis.

SOFTWARE BECOMING STANDARDIZED

At a conference sponsored by NATO in 1969, the term "software engineering" was coined. Prior to that time, the designing and writing of computer programs had been treated as an art. No two programmers wrote even a small, simple program the same way. Great emphasis was placed on elegance; very efficient code was prized more highly than was easy-to-understand code. Such attitudes and practices made software difficult and expensive to create, and even more difficult and expensive to maintain, a legacy that is still with us today.

The central concept underlying software engineering has been that software development and maintenance should be made more like traditional engineering work. Emphasis should be placed on standardized approaches, and more care taken at the early design stages, since the cost of fixing design errors escalates rapidly as the development process unfolds. Furthermore, software should be reused wherever possible.

Considerable progress in converting computer programming into an engineering discipline has occurred during the past 20 years. Nearly all organizations have adopted software development methodologies, which encompass sets of rules and guidelines for creating programs in a standardized fashion. Development tools such as Computer Aided Software Engineering (CASE) toolsets have moved programmers and analysts further away from the low-level details of specific computers, allowing them to work more productively at higher levels of abstraction. The huge improvements in the price/performance ratio of computing equipment (greatly increased computing power per dollar) that have occurred in the past two decades, have made possible a shift in the emphasis of software developers from efficiency to productivity. Today, it rarely makes economic sense for software professionals to spend time to make their code more efficient.

Thus, many of the original tenets of the software engineering philosophy have become standard operating procedure in most companies today. one key goal of software engineering has not materialized significantly to date, however -- finding a viable and cost-effective way to allow software components to be reused. The reusability problem has become so serious that today it is widely viewed as the holy grail of the software development world. object orientation offers the long-term promise of a high degree of software reusability, and the possibility of improving the productivity of software development as much as the improved methods of the previous 20 years have changed its process.
WHY IS SOFTWARE HARD TO REUSE?

Think about a company. What does a company consist of? There are people (employees), pieces of equipment (trucks, say), buildings, documents (cheques, customer statements), other companies (customers, suppliers) and so forth. Now look at the company's computer software. There you will find programs to do things such as issue an order, pay an employee, create a budget, register a payment and keep track of inventory. Application software is fundamentally process-centred. Its purpose is to allow a company to record, organize and manage information about changes to things.

This process orientation is so deeply embedded in the thinking of nearly all computer professionals that it is very difficult to "step out of the box," and see it for what it is: simply an artifact of history. The first computer software was conceived as the expression of an algorithm, that is, a set of mathematical steps for performing a calculation. The fixation of early computer engineers with algorithms -- in the late 1940s and early 1950s -- is still the basis of the world's understanding of software.

A process-centred approach to software amounts to focusing on the problem's solution (the how) rather than the problem itself (the what). When software is designed this way, the various pieces all tend to be shaped towards the solution in the designer's mind. Thus, even when the software itself is built in a modular fashion, the various modules represent pieces of the solution, that is, components of the process being represented. Such pieces cannot easily be plucked out of one application and reused in another that has a different solution. A process orientation greatly restricts the reusability of software. It has only taken 35 years to come to realize that there might he a hefter way!
A BETTER WAY IS POSSIBLE

Suppose, rather than having programs that represented paying employees, issuing orders or keeping track of inventory, you had pieces of software that represented things such as employees, orders, items that had been manufactured and so forth. For each employee, there would he a separate and distinct chunk of software on the company's computer; similarly there would he one for each customer order, for each piece of company equipment, and so on. Such a software environment would be thing-centred, as opposed to process-centred. That is the essence of the object-oriented approach to software.

In the terminology of this approach, each little chunk of software is termed an object. An object can he thought of as a self-contained combination of code and data. A software object that represents me, for example, would likely he a specific instance of the broad class of objects called employees (of UWO). The data contained within this particular object might include my name, my employee i.d. number, my telephone number and the like -- in other words, data about me. The same type of data would be included in every other employee object.

Now, suppose I get a new telephone number. How is the representation of my phone number within the object changed? As part of the code that comprises the rest of the object, there would he a small routine named, perhaps, ChangePhoneNumber. That routine would he "called" by having some other object send a message to the SidHuff object. The message would instruct the SidHuff object to execute its ChangePhoneNumber routine (or method, as it is called), and would pass the new phone number to the object as part of the message. Other routines would be included in each employee object to perform other actions upon the object's data. The object itself, then, is just a collection of the routines, together with the encapsulated data.

In an object-oriented world, each object appears as a black box to the rest of the software. All that needs to he known about an object is its name, and the various types of messages it can accept. In principle, there is no need to look inside an object to make use of it. A useful parallel here is that of electrical engineers designing a new circuit. They know they can buy prefabricated chips from various suppliers, and incorporate them into their overall design. They do not need to know how each chip works internally -- only what the appropriate inputs and corresponding outputs are.

Similarly, an object-oriented software designer only has to know the types of objects available, and the types of messages each object can receive and act upon. Programming, in an object-oriented environment, consists of defining classes of objects, then stringing together appropriate objects to perform whatever task one sets out to accomplish. The focus for an object-oriented software developer is not so much solving the problem (the old process perspective), hut rather, determining what objects are required, what the various object types should do (that is, what methods each should embody) and how the various objects relate to each other. It is, in short, a very different perspective on software development.
NEED TO STANDARDIZE

Once a full library of objects has been defined, building software systems can be done extremely rapidly, almost unbelievably so for someone schooled in the traditional procedural approach to software creation. Developing a library of objects, in a real-world setting is a major undertaking, however. For this reason, various groups, such as the open object Foundation, have been formed during the past few years to try to set standards for many types of common software objects, to standardize the language and concepts surrounding the object-oriented approach, and especially to build sharable libraries of reusable coded objects.

It may at first seem surprising that different organizations are able to share software objects. From an object-oriented perspective, however, much commonality exists across organizations, even those in very different lines of business. While some details will differ, an account object in a manufacturing firm has much the same structure as an account object in an insurance company. The same is true for customer objects, supplier objects, inventory stock objects, employee objects and so forth. Thus, a generic, standardized library of object types (or classes) can greatly accelerate the learning and startup of an organization adopting the object-oriented approach.

Obviously, some industries will have specialized requirements. Insurance companies need to define and employ policy objects, for instance, while banks require loan objects. Even here, however, insurance company associations could collaborate on a generic definition for policy objects that could be shared, and perhaps tailored by specific firms.
BENEFITS OF THE OBJECT-ORIENTED APPROACH

A number of benefits are expected to accrue to firms adopting the object oriented approach to software, including:

* A dramatically improved productivity resulting from the reusability of the software, once a company's library of object classes has been fully developed;
* Higher quality programs, because the bulk of a company's software will be built out of reusable objects, which will have been thoroughly tested and debugged well ahead of time;
* Improved software flexibility, since, just as with toys made from Lego pieces, applications programs will be able to be disassembled and reassembled quickly and easily as the organization's shape and requirements change;
* Simplified and reduced software maintenance;
* Enhanced data integrity, resulting from the black box nature of software objects;
* Improved ability to handle complexity, since, as experience to date has shown, it is possible to build far more complex and challenging systems, with fewer people, when they are built using an object-oriented approach.

THERE ARE SOME DRAWBACKS

The adoption of the object-oriented approach is not something that can be undertaken quickly; it requires a long-term perspective. Some of the potential problems an organization faces in moving to it include:

* The object-oriented approach requires a company's software professionals to learn a whole new way of thinking. In particular, it requires new, unfamiliar programming methods and languages, such as C++, Smalltalk or perhaps visually-oriented languages, such as Visual Basic or Objectvision.
* At present, libraries of object classes are limited and far from complete. Companies adopting the object-oriented approach will have to spend considerable time investing in the design and creation of their own object class libraries. Sharing the effort with other firms will mitigate this problem somewhat, however.
* The object-oriented approach is not compatible, at least today, with most purchased software.
* There is a human harrier to be overcome. Many computer professionals are still skeptical of the value of the object-oriented approach, much as they have been, until recently, skeptical of the benefits of personal computers. They are often unwilling to surrender the years of investment they have made in the process approach to software creation, to learn the new methods.

BEGIN BY BEGINNING

The drawbacks to adopting the object-oriented approach are considerable and should not be underestimated. Nonetheless, as a long-term solution to the problem of software reuse and development productivity generally, the object -oriented approach offers a compelling alternative - indeed, arguably the only realistic alternative-to current process-oriented methods. Appropriate steps you might consider for your organization to develop a better appreciation for object-oriented methods include:

* Get your organization involved with one or more groups developing standardized objects;
* Provide appropriate training for a group of your computer professionals to get them up to speed in object-oriented development methods;
* Arrange some small-scale experiments that will allow this advance team to try out different object-oriented techniques and languages;
* Undertake a series of pilot projects of small but increasing scale, in which the advance team applies the new methods to real problems in the organization;
* Work towards architecting and developing your organization's own object class libraries;
* Actively seek out other organizations with which you can share your firm's experiences in the object-oriented approach.

OOP IS NOT A QUICK FIX

Very few organizations, other than software companies, have yet undertaken wholesale conversion to object orientation. Partly this reluctance is due to the huge mountain of existing software most companies currently own, which was built using traditional methods and tools, and which must be maintained for years to come. Even if the world experienced a massive conversion to the object-oriented philosophy tomorrow, it would take many years to replace the existing inventory of company programs with new object-oriented systems. Any talk of instant benefits from adoption of the object-oriented approach, therefore, is ridiculous. Conversely, for years companies have sought solutions to their software crises - costly development, low productivity, difficult maintenance, inability to reuse their code - with little to show for it. The object-oriented approach, an entirely new paradigm for software creation and maintenance, holds the key to a door leading out of the current morass. While not a short-term fix, by enabling the sharing and reuse of software, the object-oriented approach offers a long-term solution to today's software crisis.