Back to the Future: OOP & MacApp

By Jean-Denis Muys-Vasovic, Argenteuil, France

Back to the future: OOP & MacApp

(or: The Hitch Hiker’s Guide to Objectivity)

Introduction

The seventies saw the increasing popularity of a programming technology known as “structured programming”, of which the best witness is the good & famous book by Niklaus Wirth: Algorithm + Data Structures = Programs. The design of programming languages followed this trend, beginning with Pascal, and ending with Ada or Modula II.

On the other hand, the eighties have seen the birth of another programming concept, whose roots can be found in the seventies as well: Object-Oriented Programming. This technology has not yet got its “Algorithm + Data Structures = Programs”, though a few good books are around. The roots of Object-Oriented Programming are buried deep in the past, and go back to the early seventies when a research team at the Xerox PARC (Palo Alto Research Center), including (sounds familiar?) Alan Kay, Ted Kaehler, Larry Tesler, started to design Smalltalk And yet Object-Oriented Programming (OOP in short) is the way of the future. The object of this short article is to explain some of the hows and whys. Follow me if you dare to The Restaurant At The End of Programming Knowledge.

Object-Oriented Programming

What is Object-Oriented Programming by the way? This question, often asked, is much more seldom answered. The fact is that it is difficult to answer it without calling on associated definitions:

Object-Oriented Programming is the compliance to the technology by which a computer program is designed and written around objects.

Above all, Object-Oriented programming is a technique for programming, a set of paradigms for writing “good” programs. The main characteristics of OOP is that it is consistent with the way in which humans think about solving problems. It consists of identifying objects and what is to be done with those objects as specific steps in a problem solution.

But all this won’t be clear until the definition of “object” is given. An object is first a data type. At first glance it can be thought of as a record (for Pascal programmers) or a struct (for C programmers). As such, it defines a set of fields which will contain related data, as for example, the name, age, sex and social security number of people. But what makes an object different from a mere struct, is that it also contains behavioral information, let’s say procedures. And this brings it to life (pict 1). So fields convey the static and declarative information of the object, while procedures convey its dynamic and operational information. Some self examination will show you that this is the way people solve problems in everyday life. In OOP language, the procedures are called methods. And when you call the method, you say that you send the object a message, and that the object answers the message by executing the method. This is completely metaphorical, but it helps a lot. And in C, you could indeed build objects as structs in which some fields are pointers to functions.

In fact, it would be wasteful to use memory in every object just to contain the pointers to all of its methods, which are probably the same for a lot of objects. That’s why the methods are defined in an object template, which is used to mold new objects of the same kind. This template, in fact the actual type definition, is called a class. It defines the structure and behavior of all objects of this kind, called instances of the class. For example, you can define a Car data type, with power, size, color, speed fields, and start, stop, turn methods. This is the Car class, instances of which could be myBMW, yourPorsche, hisToyota objects. The Class is a data type definition, while the instances are the real variables (picture 2).

But OOP goes a little further. All these classes are not just there ignoring each other. Just like in real life people classify objects (i.e. real objects, but also animals, problems, music and people ) in categories according to their similarities, in the same way, OOP introduces inheritance (pict 3). Look at the biological classification of animals: it is an inheritance tree. It says (forgive the errors, I am not a biologist):

- There is the biggest class, instances of which are all animals

- This class has some subclasses, including (but not limited to) mammals, insects, fish

- The mammals class has itself subclasses, including rodents, apes

- The last subclasses, which have no subclass are the species, including rabbits, men, cows

- The rabbit I bought last week is an instance of the rabbits class, but also of the rodents class, and mammals class, and the animals class (and probably several intervening classes).

What is important to notice is that a subclass inherits everything from its parent class (or superclass), including the fields and the methods. But it can itself be specialized (by adding fields and/or methods), and/or customized (by replacing some methods, you override those methods).

For example the birds class tells us that a bird can fly. The albatrosses subclass is specialized and tells us an albatross can fly long and well. The ostrich class is customized and tells us an ostrich cannot fly. In this way, every bird will understand the message “fly”, but will answer it differently, including ostriches which will say “no”.

Structured programming introduced code structuring. Inheritance introduces data structuring. The benefits are similar. This inheritance process allows a very different programming style, in which you program mostly by differences, only specifying the differences between your class and a preexisting class.

Object-Oriented Languages

As it should now be clear, it is possible to program “Object-Oriented” in any language but the poorest. But it is far from sufficient for a language just to enable Object-Oriented Programming. It must also support Object-Oriented Programming. To enable means to make it possible, but maybe painful, difficult, tedious, awkward. To support it means to make it easy, safe, efficient, fun.

More specifically, a language can be said to be Object-Oriented if it satisfies four requirements, namely encapsulation, abstraction, inheritance, and polymorphism.

Encapsulation is satisfied when the language supports the definition of data types in which data and procedures are encapsulated, i.e. tied together. This is the very definition of the word object (in our context of course). Typically, the procedures act on the data. The module concept found in languages such as Ada or Modula II fulfills this requirement.

Abstraction is satisfied when the language supports the definition of abstract data types. An abstract data type is a incomplete type definition, which cannot be used alone, but only together with another data type. For example, a stack (whose methods could include push, pop, top ) is an abstract data type, because you must specify a stack of what. In Object-Oriented languages, you often define abstract classes which have no instance, but are there to be subclassed. Their methods typically do nothing and are to be overridden by subclasses. Abstract data types such as the stack can be defined in Ada.

Inheritance is satisfied when the language supports the definition of data types by specialization or customization of preexisting data types. In that case, the new data type inherits both the data and the procedures from its parent data type. It can thereafter add new data or new procedures, and replace part (or all) of the behavior of the parent class. Ada does not support inheritance.

Polymorphism is satisfied when the language supports the process by which the same procedure call can result in the execution of different pieces of code, depending on the type of its arguments. This is typically what is reflected in the message metaphor: the same message can be sent to two objects whose answer will be different because their methods are different. Ada does support a limited form of polymorphism through its overloading mechanism.

Let’s first say that Ada is definitively NOT Object-Oriented, as it sometimes claims to be, though it’s a very near miss. Before giving you some names of real Object-Oriented languages, let me give some other desirable features, which an Object-Oriented language could have:

The Object-Oriented mechanisms must be integrated

The Object-Oriented mechanisms must be combinable

The Object-Oriented mechanisms must be general purpose

The Object-Oriented mechanisms must not impose overhead over programs which do not use them.

The Object-Oriented mechanisms must not depend on other mechanisms (in other words, what you don’t know won’t hurt you).

You may have recognized the implementation goals of Bjarne Stroustrup, the designer of the C++ language. Of course, C++ is a leader among the contenders in the OOL war. C++ is a strict superset of the C language, from which it inherits the efficiency. Others are Smalltalk-80, the father of OOP, which is more than an Object-Oriented language, its also an Object-Oriented programming environment and an Object-Oriented philosophy. Second class contenders are Objective-C, and Object Pascal for example. So far, Object Pascal has been very important at Apple because it was designed by Apple, together with Pascal’s father, Professor Niklaus Wirth. It is even more important, because Object Pascal is the language in which MacApp was implemented. As C++ is to C, Object Pascal is a strict superset of Pascal, though much simpler than C++.

Benefits and Methodology

The benefits of OOP are numerous. As stated above, the paradigm is closer to the way humans think. But more practically, objects are small self contained software computers. Once they are debugged, they work. They can be considered as black boxes, or better yet, as actors to whom you delegate tasks, and who delegate subtasks to other objects.

Another advantage of OOP worth noticing is that you do not have to remember which procedure acts on which data type. Just send the message to the object which will answer correctly. Of course you still have to write as many methods as concerned data types for a given operation, but you don’t have to remember any more the name of the actual procedure, just a symbolic, generic message name which describes the nature of the procedure.

As a side effect of using OOP, you will find that your control structures will be a lot simpler. You won’t have large and tedious switch (or case) statements any more. The dispatching can most of the time be done by the language itself through message passing and method selection. Moreover, the OOL dispatching can be quite efficient.

And indeed you often end up with a program which is smaller and faster than it would have been if developed with traditional technology. Of course, a method call is on average slightly slower than a traditional procedure call. But this overhead is constant (and small). In particular, the method call time does not depend on the class in which the actual executed method is found, or on the depth of the inheritance tree to walk through before finding the method. Moreover, a large number of method calls can be optimized to become real traditional procedure calls: those for which the actual executed method is not ambiguous. An important fact to notice is that this optimization can be done at link time. Another reason why the program is often shorter and faster is that it is actually easier to design good and efficient algorithms with OOP.

But the real advantages of OOP lie in code extensibility and reusability. You don’t even need the source code of a class to use it, subclass it, extend it, or customize it. That’s why a lot of Object-Oriented Languages (including Smalltalk and Objective C for example) bring with them a large amount of predefined common use object classes. If you are not satisfied with their behavior, you don’t have to rewrite them from scratch. You just have to subclass and override. But what can be done with the code of others, can - even more so - be done with your own code. It is indeed a lot easier to reuse your classes from one application to the next.

As a global result you will find that your development times are shorter. And the time gain is more and more important as your experience improves and as you reuse more and more of your code from one application to the other. Of course to extract the largest gain from OOP, you will have to understand the methodology. And that is only learned through experience. There is no magic rule which could tell you how to design THE good object and method structure.

In terms of choices for subclasses or subclass protocol, there is more than one solution for any given problem. Thus, Object-Oriented problem solving requires creativity and intelligence in establishing the “best” solution to a problem.

The process of deciphering and designing the objects which are part of a problem solution is often relatively easy. The process of finding the most efficient generalization of those objects is often a difficult task, more of an art than of a technique! Two design methodologies can be used (but not interchangeably): top-down and bottom-up.

Top down design methodology is often used with traditional structured programming. You begin by stating the problems to be solved as general tasks. And you proceed by dividing the tasks into subtasks of decreasing size, up to the point where each subtask is simple enough to have an obvious solution.

Bottom-up design methodology is often used in threaded coded languages like Forth. It consists in designing very small and elementary low-level building blocks. Thereafter, the building blocks are used to design one level higher building blocks. And you proceed that way, designing higher and higher level building blocks, up to the point where one building block actually solves your problem, maybe with the help of others. You can easily see how well the design methodology fits in the Object-Oriented Programming paradigm. Building blocks are objects (or the other way around if you like). And contrary to plain vanilla Forth for example, they are customizable. You design variants of existing objects to fit more closely your problem, just by subclassing and overriding.

MacApp

Now, what is MacApp? MacApp is NOT an Object-Oriented Language. MacApp is a class library which includes a lot of already debugged object classes. The objects of MacApp handle all the Macintosh features which are always found in a Macintosh application, including handling windows, menu, undo, printing, saving and opening, and a lot more. MacApp also does a lot of things which are very rarely done in commercial applications, including safe memory management, efficient error handling As an effect, MacApp applications are often a lot more “bombproof” than other applications, especially in hostile executing conditions.

So MacApp is an Object-Oriented Application Framework. Object-Oriented because it is built around objects rather than procedures and functions. Framework because MacApp provides a general structure for any application. MacApp implements for you windows, mouse handling, printing And Application because MacApp can only be used to write applications. You won’t be able to use MacApp to write desk accessories, device drivers, INITs, cdev, etc.

MacApp is therefore a large code library. It is written in Object Pascal with some assembler (which by the way tells you that Apple has an Object-Oriented assembler). To use MacApp, you currently must use MPW, with either MPW Pascal, TML Pascal II or p1 Modula II. However Symantec announced its intent to support MacApp under LightSpeed Pascal 2.0. and other third parties are encouraged to support MacApp in their development environments too. All the MacApp code is organized as a main code unit and optional parts. For example, the dialog building block is optional. The mandatory part contains general utility classes as well as the main MacApp classes.

Now, why would you want to use MacApp? Try to look at what Macintosh programming consists of without MacApp. First of all, you have to know the Toolbox. All of it. That means having read and understood all but the most exotic Inside Macintosh chapters. You must deal with a complicated and large main event loop. You must dig out what you can and cannot do for the sake of past, present, and future compatibility. You must program defensively, which means foreseeing every imaginable run-time circumstance. You must handle all memory and error situations. Above all, for each and every application you develop, you have to start over again, reinventing the wheel. Of course you don’t start from scratch every time. But there are a lot of pitfalls in reusing an application as a basis for a new one. Variables change, behavior changes, structure changes.

Now with MacApp you have reusability without the pitfalls, thanks to its Object-Oriented structure. You roughly have to fill in the blanks of a template application. The responsibilities in the application are divided between MacApp and you. MacApp does everything it can know, but nothing it might have to guess. Instead of guessing, MacApp will call your own code. All in all, you can trust MacApp, it will do its part of the job.

There are a lot of benefits in using MacApp. First to benefit will be the users of your application. The reason why is that the typical Macintosh user expects all his/her applications to work the same way. Most of the time, he/she doesn’t even read the documentation. With MacApp, your user will feel at home with your application, because MacApp was written by Apple in strict conformance to its own User Interface Guidelines. Moreover, your application will be compatible with all currently available Macintosh systems, and you can expect it to stay compatible with future hardware or software architectures. For example, an application written with MacApp works without a hitch under A/UX. Of course, all this will be true only if you stick to MacApp rules as defined in its documentation. You will always be free to break whatever you like.

Last, but certainly not least, you will also benefit. You will benefit because you will be able to concentrate on the interesting part of your application. MacApp will take care of the rest. You will benefit because your application will be very modular, and organized along human-like lines. You will benefit because you will always have a running, testable application which will keep your boss happy. And you will benefit because your development cycles will be much shorter, and thus more productive. The high level symbolic Object-Oriented debugging tools that MacApp provides will shorten your development cycle even more.

Drawback? Which drawback? Oh yes, there’s always a drawback! Well, the drawback is that you will have to learn MacApp. It will take some time. How long depends on you, on whether you have any OOP experience, and how much, and on whether you have any Macintosh programming experience, and how much. On average, I would guess the learning time is somewhere between two and three months. But the reward far exceeds the journey. On the other hand there are no other drawbacks. There is no significant speed penalty. There is no significant size penalty.

Conclusion

If you have any objection concerning the objectivity of this paper, or if you find its very objective objectionable, don’t hesitate to object. But the fact is that the future of OOP is very bright in Life, the Universe, Computer Science and Everything. It has already given birth to some very strong new programming languages, including Smalltalk-80, C.L.O.S., Objective-C, and of course C++. Others are probably on the way. Object-Oriented Programming technology will probably increasingly be used for software development, at both application and system level. And I can tell you that Apple is committed to supporting that old paradigm strongly in the future.

In the meantime, So Long, and Thanks for All the MacApp Apps!

Acknowledgments: Douglas Adams provided much of the inspiration for this article.

Bibliography:

Object-Oriented Programming for the Macintosh, Kurt J. Schmucker, Hayden Books, 1986.

Object-Oriented Programming, an Evolutionary Approach, Brad J. Cox, Addison Wesley, 1987.