Volume Number: 20 (2004)
Issue Number: 4
Column Tag: Programming

REALBasic Best Practice

by Guyren G Howe

Object-Oriented Programming with REALbasic

Welcome to the first issue of my regular REALbasic Best Practice column. Each month, I'll tackle the question of how one can get the most out of REALbasic. I'm going to mix things up: reviews, advice, adapting general programming techniques to REALbasic, but always with the theme of "best practice".

I'm going to start with something I touched on in last month's review: REALbasic's unique object-oriented programming feature, that I call the Event Model. This article assumes you are familiar with the basics of object-oriented programming.

A little history will help us to understand where we are.

REALbasic's original designer, Andrew Barry (who sadly is no longer with REAL Software) came up with what I believe is an entirely novel, and powerful object-oriented programming model for the very first version of REALbasic, which he prosaically called Events. To distinguish this feature in general from particular events, I'll call the feature the Event Model.

Because it was too different from what folks were used to, and because it made porting code from other languages more difficult, Andrew bowed to pressure, and also provided support for basically the same OOP model that Java supports (single inheritance with interfaces).

Once Andrew left, the programmers and managers at REAL Software have, to my mind, quite reasonably focused on the many other ways in which they wanted to improve REALbasic, and they've done a bang-up job of that. But they have, in some ways unfortunately, lost focus on this cool language feature. It's still there, it still works just fine, but REAL doesn't correctly document it, they don't much talk about it, and they haven't extended it in a few obvious ways that would make it just about perfect.

You need the Events Model because it makes code development and maintenance easier, and because the result of code changes in a superclass under the Events Model is much more predictable than with traditional method overriding.

In fact, the Event Model brings such clarity, and maintainability benefits that, except for doing one particular thing, Events are superior in every way to traditional method overriding.

I will now explain what the Event Model is, and provide an example to demonstrate the advantages I just mentioned.

What we're about here is the relationship between the code in a superclass, and the code in a subclass. In Object-Oriented Programming languages, one of the most interesting problems is how the language should support code re-use down through a class hierarchy. We want to be able to provide some code in a superclass, and then have code in a subclass somehow extend or modify that code -- and to perform further modification, and extension of behavior on down a class inheritance chain.

Every mainstream Object-Oriented language does this by allowing a subclass to override methods on its superclass, entirely replacing that code, and then allowing the subclass to invoke methods defined in the superclass, including quite often invoking the superclass's version of the overridden method. A common pattern will be a method on a superclass that provides code to complete some but not all of some task, with the expectation that a subclass will override the method, carry out the rest of the task, and at some point call the overridden method to do the common part.

Notice that in this scheme, the subclass is entirely in charge of the final carrying-out of the method. In particular, it is up to the subclass to determine when and how to invoke the code in the superclass as part of its design for the complete method. In an inheritance chain, control is usually passed in this way from the bottom up, with a subclass invoking the most immediate superclass's methods as it desires.

There are two serious problems with this model:

Good object-oriented design will push as much code as is reasonable toward the top of the class hierarchy, but that code has to be written without being able to rely on when and how it is being invoked by the subclasses. Even in code you're entirely writing yourself, you have to remember what conventions you intended to employ in this relationship, possibly when you come back to code six months after you wrote it; and

It is easy for a subclass to override a superclass in such a way that, although you want to make a change in behavior that is the superclass's responsibility, you can't do it without also having to change some or all of the subclasses' code as well.

The Events Model, on the other hand, turns this whole thing on its head, allowing the superclass to provide subclasses with explicit opportunities to act, and letting these opportunities pass down the inheritance chain rather than up it. This very neatly avoids both of the problems mentioned, as we will see.

Let's consider a simple example that clearly illustrates the advantage of the Events Model.

Assume we're writing an application with a non-standard user interface, so we use custom controls drawn using graphics primitives.

We create an abstract Control superclass, whose task it is to keep track of where the control is on the screen. We give it a Draw method.

Next, we have an abstract Button subclass of Control, with code to draw a common background color and some other graphic details shared by all the buttons in the program.

We then create a whole variety of button subclasses for various tasks.

So we have an inheritance hierarchy that looks like this:

When we use method overriding as our means of extension, as we go up the chain, each class overrides its superclass's Draw method and invokes that method as part of its own draw process.

This means that a control at the bottom of the chain will have a Draw method that looks something like this:

Sub Draw
   Super.Draw
   ... code to draw specifics on top of background provided by super
End Sub

Pseudo-code for Button.Draw
Sub Draw
   Super.Draw //Work out where I'm drawing
   ... code to draw background
End Sub

Pseudo-code for Control.Draw
Sub Draw
   ... code to work out where to draw
End Sub

This is all fine. We get nice abstraction and code re-use, all the usual OOP goodness.

But a problem arises when we make changes to the superclasses. Let's say we now want to make all our buttons have an Aqua-style highlight: we want to take whatever the subclass produces, and run a graphic filter over that to make it look like it's sitting in a drop of liquid.

We simply can't do it without wholesale code rewriting. With this inheritance scheme, the superclass has no way to obtain another chance to act after the subclass is done calling on it. The only solution is to make changes to every bottom-level subclass, even though we really don't need the subclasses to do their part of the drawing task any differently. A change in the shared logic can't be implemented in the shared code.

An Event declaration is essentially a declaration of the interface for a method that subclasses can implement (this "method" is called an Event Handler), that can only be called from the declaring superclass. Once declared, the superclass can invoke the event handler just like a regular method or function.

When an event handler is called, the most immediate subclass implementing a handler for it gets to act. If no subclass implements a handler, the call is ignored (if the call is to a function, a "null" -- 0, Nil, False, the empty string, and so on -- value is returned).

Note that once a handler for an event exists in the hierarchy for a particular class, further subclasses don't even see the event. Frequently, the subclass will do whatever it needs in response to the event invocation, and then invokes a new event it has declared, having exactly the same name and arguments, providing further subclasses with the opportunity to act.

Note that rather than the ill-defined mess that is method overriding, the language is providing a well-defined protocol for superclasses to delegate specific responsibilities down to their subclasses.

A good example of this scheme is the REALbasic EditField control, which declares a KeyDown event as a function with a string argument, returning a Boolean value. The event indicates to a subclass that the user has tried to type something into the EditField. If the subclass provides a handler for KeyDown and returns True in that handler, the keystroke is ignored. Otherwise, it is displayed in the EditField normally.

This scheme makes it easy to extend the EditField to create a control that, say, only lets the user enter a number.

Back to our example of custom buttons.

Under the Event model, rather than each subclass overriding its superclass's version of Draw, only the top-level Control class has a Draw method. In addition, Control declares a new DrawEvent event. Each subclass will provide a handler for the event, and will also declare a new version of the event, calling it at the appropriate time. So now we have:

Pseudo-code for Control.Draw
Sub Draw
   ... code to work out where to draw
   DrawEvent //Ask subclass to now draw itself there
End Sub

Pseudo-code for Button.Draw
Sub DrawEvent
   ... code to draw background
   DrawEvent //Ask subclass to draw its content atop the background
End Sub

Finally, the class at the bottom of the chain just does its part of the task.

Pseudo-code for a Draw method at the bottom of the inheritance chain
Sub DrawEvent
   ... code to draw specifics on top of background provided by super
End Sub

Now what happens when we want to add the new graphical tweak? We only have to change the code in one place, Button's DrawEvent handler, which now looks like this:

Pseudo-code for an extended Button.Draw

Sub DrawEvent
   ... code to draw background
   DrawEvent //Ask subclass to draw its content atop the background
   ... code to draw water on top
End Sub

Once you get the Event Model, you miss it in every other object-oriented language.

There are many advantages to the Event Model. For example, if you're working with a team of programmers, or you're shipping a framework for others to use, with method overriding, you need all sorts of tortuous documentation about how subclasses should interact with their superclasses. With the Event model, the language itself enforces the relationship. So not only does the Event Model make maintenance easier, but it better explicates the logic of the program.

...except that there is one feature for which we still need overriding: functions for which the subclass should return a more specific type than the superclass does. The canonical example of this is a generic data structure. We can write, say, a generic data store base class that stores Objects. But this is needlessly difficult to use as it is, because we have to cast the objects we get from it to a more specific type in order to use them, every single time we use this class.

What we want is to extend the generic data structure to one storing objects of more specific types -- a list of controls, for example, where the casting to the correct return type is done for us. Unfortunately, the Events Model provides no way to do this, because the function that yields the objects must be declared to return values of type Object (or perhaps Variant).

The method overriding paradigm provides what we need here. We create a Protected function toward the top of the inheritance chain, then declare and invoke suitable events so that subclasses can carry out the function. Then we create a 'public face' on that function in the bottom-level class in the form of a function that returns the type we want, and have it just call up to the protected internal function, at the top of the class hierarchy, that provides the generic functionality.

So the call sequence goes like this:

We invoke the public Get() function on the bottom-level ControlStore class.

ControlStore invokes the protected GenericStore.GetInternal() function on the base GenericStore class.

GenericStore invokes its GetEvent.

The most immediate subclass declaring a handler is GenericList, which fetches the result, returning it to GenericStore.

GenericStore returns the result to ControlStore.Get().

ControlStore.Get() casts the result to a Control and returns it to the original caller.

Interestingly, notice that in a sense, we aren't actually extending the GenericList class's behavior: we're actually restricting it. All of this calling up, and back down the inheritance chain is a little weird when you first do it. Quite often, in the bottom class, you will be creating the public function, calling the protected version in the base class, then turning around and handling the event again the same bottom-level class. When I first started doing this, it felt a bit baroque, to be going up, and then down the inheritance chain like this, and having the public function actually fulfill its role in the event handler. But I'm quite comfortable with it now because I don't see overriding as an extension mechanism at all any more.

It might help to see that in fact, you could do this with just Events by creating a wrapper class that does the type casting. I just prefer to do it all within the same class hierarchy, because it's cleaner and clearer to do this rather than create the generic store, the wrapper class, and suitable Interface.

It would be nice if REALbasic had templates, or if some other mechanism could be found that let us stick entirely to the Events Model without any of that, but this constrained use of overriding is just fine for now.

I'd like to see REAL Software emphasize the Events Model in their documentation. I'd also like to see them look into making some improvements to the Events Model to make it more powerful.

One obvious improvement would be to provide a compiler directive that could execute different code depending on whether an Event has a handler available or not. A common style of programming you'll want to do with Events is to provide default behavior at some point in the code for a class, but allow a subclass to extend or replace that behavior (as the EditField does with the KeyDown Event).

The only way to do that right now with Events is to call a function-style Event Handler, and do your default behavior if you get back the "null" response. But in some circumstances, you need to treat the null value as a result, rather than an indication that you didn't provide an event handler, and you wind up doing all sorts of gymnastics to work around the problem.

I hope I've convinced you of the virtue of the Events Model. Once you "get it", in my experience, you'll wonder how you ever lived without it.

Guyren G Howe works in artificial intelligence research, after years of work as a technical writer and developer. He is married with one child, is an Australian, and lives in Austin, Texas. Guyren has been working with REALbasic for several years. Most notably, he wrote the REALbasic Curriculum Project, an extensive computer science curriculum, for REAL Software (available from the REALbasic website).