What's top down in OOP


Object-oriented programming is a current favorite topic at publications and conferences. It is not only referred to as a way out of the software crisis, but also as a boulevard for software design and implementation. But it hides its character - not only for IT laypeople - initially behind the wall of a new type of vocabulary.

What does the production of software today have in common with that of handguns in the 18th century? An ineffective manufacturing process that also has a negative impact on the later life cycle of the product. As for the older problem, Eli Whitney came up with the pioneering idea in 1798.

From then on, rifles were no longer made as a whole by a gunsmith, but specialists took over the production of standardized individual parts, which could then be put together to form the finished product.

This change not only made repairs and maintenance work easier, but also enabled the corresponding components to be exchanged between different weapons.

Recycling should reduce costs

In the opinion of many experts, such a transition to industrial production methods is also pending for software development. The aim is to reduce development and maintenance costs with the help of reusable software components, which should also be very reliable and easily expandable. As the software crisis shows, this cannot be achieved with today's structured programming method.

The software packages created in this way are usually complex individual pieces, the components of which are interrelated in a variety of ways. Changes and expansions in such a system are hardly manageable in terms of their effects, and the costs they cause often exceed those of a new development. The reuse of individual components of such a system is also rather the exception.

In the last two years in particular, experts have promoted object-oriented programming as a way out of this dilemma. Associated with it is a completely new terminology with terms such as class, inheritance, polymorphism, etc., which initially make access more difficult. In the absence of a scientific foundation, as is the case for relational databases, these terms have developed quite differently in the existing programming languages. In the following, I would like to introduce the basic ideas and terms of object-oriented programming, independent of the programming language, and examine to what extent they are suitable for contributing to the solution of the problems mentioned above.

Nowadays it is undisputed that the creation of complex systems can only be managed through modularization. But which criteria are to be used for this?

The structured programming is based on a functional breakdown of the overall system into subsystems down to the level of individual subroutines.

Object-oriented programming breaks radically with this view in favor of the attitude that modularization is given in a natural way by the things to be processed in the real world. An "object" is a software component that consists of data and procedures for processing them. The data of an object, which can of course change during the execution of a program, are called "variables" as in traditional programming. In object-oriented terminology, "procedures" are the methods of the object.

An example may serve to explain the new terms. A rectangle in a drawing program is characterized by the screen coordinates of its corner points. The variables of the rectangle object are the screen coordinates. Methods are the operations that can relate to the rectangle, for example "Draw", "Create diagonal", "Move", "Zoom" and "Calculate area".

An essential characteristic of an object is that the values ​​of its variables can only be accessed using the methods belonging to the object. This data encapsulation mechanism protects the data of an object from unwanted or uncontrolled changes - think of common variables in conventional programs - and also allows the object to be used without knowing the details of the implementation of its methods (principle of secrecy).

Usually a program system will process many objects of the same type, and it would not be efficient to store the same methods separately in each individual object.

The concept of "class" offers an elegant and effective method of avoiding this expense. Classes represent templates for defining the methods and variables of similar objects. The objects themselves are the "instances" of a class and only contain the concrete values ​​of their variables. In the context of our example, this means introducing a "Rectangle" class, in which it is specified that its screen coordinates and the above-mentioned "Drawing" etc. methods belong to a rectangle. A concrete rectangle R1 is then an instance of the "rectangle" class, an object.

A central mechanism of object-oriented programming is the "inheritance" of the properties of a class on subclasses. Such a subclass is created by specializing an existing class and automatically has all the variables and methods of its superclass. In addition, however, it can also introduce its own methods and variables and overwrite inherited ones. This inheritance mechanism can theoretically be continued over any number of levels, with only the extensions and changes to the level above having to be implemented on each new level of the class hierarchy.

Generic class at the top of the hierarchy

At the top of the hierarchy there is often a "generic class" that is introduced for organizational reasons or to define the variables and methods of its subclasses. Generic classes have no instances.

To continue our example, it makes sense to introduce a generic "Polygon" class, in which the "Draw", "Move", "Zoom" and "Area" methods are again defined. The already known class "rectangle" then no longer needs to implement this, but inherits it from "polygon". Since the formula for calculating the area for rectangles is very simple, it is implemented in "Rectangle" and the method of the same name from "Polygon" is overwritten. Only the "diagonal" method, which refers to a peculiarity of rectangles, does not exist in "polygon", so it represents an extension of the superclass.

The structure of such class hierarchies corresponds exactly to the way in which we analyze our environment in everyday life and store our knowledge. Object-oriented programming offers a natural way of building complex, but nevertheless easily understandable software systems, consisting of largely independent objects that only interact with one another via the methods of their class.

This now raises the question of how such a software system works, how activities are initiated and run. The key to this are messages that go back and forth between objects. A message consists of the name of the addressed object, the call of a method of this object and any information required to execute the method in the form of a parameter list. An object that receives such a message searches, starting with its own class, its class hierarchy from bottom to top for the implementation of the addressed method and executes the version found first. This is also how the search for the definition of variables is carried out. As a rule, after the desired action has been carried out, a confirmation is sent to the sender, for example in the form of a return value.

In our example, if a rectangle R1 receives the message to zoom by a factor of 1.5, the implementation of this method is found in its superclass "Polygon". The method for calculating the area can be found in its own class. Furthermore, the transfer of the magnification factor as a parameter belongs to zooming, while the method for calculating the area works without parameters. If a "triangle" class is introduced as a further subclass of "polygon", which like "rectangle" has its own method for calculating the area, this can also be referred to as "area", since each object has messages with the same name according to its own implementation of the Method processed. This ability to interpret a message differently through different objects is called polymorphism.

In practice there are still difficulties ...

Object-oriented programming can undoubtedly contribute to the desired industrial production of software. The model of classes in connection with inheritance provides a good basis for creating reusable software modules. On the one hand, a class forms a closed unit that must be made available in class libraries in order to enable integration into any system. Data encapsulation and polymorphism are of great importance here. On the other hand, it is easily possible through inheritance to use existing classes as superclasses and to derive new ones with special properties from them.

A decisive advantage of this concept is the possibility of building on already tried and tested software modules and thus considerably reducing development and testing times. There are also favorable prospects for the maintenance and care of existing systems.

Changes in the implementation of the methods of a class have no external effect as long as the parameter list for calling the method remains unchanged. Since changes are automatically propagated down the class hierarchy, no great implementation effort is required. Even extensive changes remain manageable, since the networking of object-oriented program systems is nowhere near as complex as in conventional systems.

... but the future is bright

In theory, the object-oriented future looks very promising.However, the road to the ultimate breakthrough in practice will be accompanied by a variety of difficulties, from struggling to accept the new mindset, developing standards and truly reusable, environment-independent class libraries, to providing appropriate development techniques and environments. But even Eli Whitney's idea had to overcome a lot of resistance in order to become what it is today: a matter of course!

OOP approaches have been around for 25 years

The basic concepts of object-oriented programming are by no means new. The first programming language to use the term class was Simula 67, an object-oriented extension of Algol that originated in the Norwegian computer center in Oslo in the mid-1960s.

Just as Simula is not a purely object-oriented language, most of the languages ​​known today as object-oriented are hybrid languages, i.e. extensions of conventional languages ​​to include various object-oriented features. In addition to Algol (with the Simula extension), the following are basic languages: Pascal (Turbo-Pascal 6.0, Quick Pascal), C (C ++, Objective C), Lisp (CLOS, Flavors, XLisp). As a rule, the basic language is expanded to include a class construct with inheritance options. In contrast, there are the pure object-oriented languages ​​such as Smalltalk and Eiffel.

Smalltalk, which the programmers at the Xerox Palo Alto Research Center developed in the early 1970s with the aim of creating an expressive, ergonomic user interface, was certainly the most widespread. Smalltalk is the origin of many components of graphical user interfaces that are taken for granted today, such as mice, window technology, pull-down and pop-up menus.

After an entire issue of the computer magazine Byte was devoted exclusively to Smalltalk in 1981, the general public also turned its attention to object-oriented software development, but almost another decade passed before the idea finally made its breakthrough. Even today, many object-oriented languages ​​are more experimental in character, but those used commercially are becoming increasingly important.