TweetFollow Us on Twitter

Object-Oriented Programming with REALbasic

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

REALBasic Best Practice

by Guyren G Howe

Object-Oriented Programming with REALbasic

Getting the most from a unique Object-Oriented paradigm

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

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.

Why You need events

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.

Events vs 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.

An Example

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:


Figure 1: A simple inheritance hierarchy

The Method Overriding Way

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:

Pseudo-code for a Draw method at the bottom of the inheritance chain

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

Button.Draw, in turn, has code like this:

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

Control.Draw has code like this:

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.

The Event Model

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.

The Button Example, Using the Event Model

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:

Control.Draw has code like this:

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

Button's DrawEvent handler looks like this:

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.

The Exception that Proves the Rule

...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:


Figure 2: Using Method Overriding to Create a More Restricted Type

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.

Improvements Wanted

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.

Conclusion

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).

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Latest Forum Discussions

See All

Soft Drummer (Music)
Soft Drummer 1.0 Device: iOS Universal Category: Music Price: $14.99, Version: 1.0 (iTunes) Description: Soft Drummer is the closest thing to a pro session subtle drummer in your pocket. Easy to use and fast, it's much more than a... | Read more »
Is GO Gear the Pokemon GO map app you...
Now that we've settled into something of a Pokemon GO status quo, the number one desire of most players can best be summed out by modifying a quote from Rod Tidwell of Jerry Maguire: "Show me the Pokemon!" [Read more] | Read more »
Rodeo Stampede update: Mountains, new an...
The Savannah and Jungle were just the beginning in Rodeo Stampede. Get ready to head for the Mountains. I think I heard that in a beer ad once. [Read more] | Read more »
COSMOS RINGS (Games)
COSMOS RINGS 1.0.0 Device: iOS iPhone Category: Games Price: $5.99, Version: 1.0.0 (iTunes) Description: This game cannot be played without the Apple Watch.Released anniversary sale until August 31,2016 PST! A tragic tale of time's... | Read more »
How to get started selling on Mercari
As far as ecommerce has come over the last decade or so, there's still a tremendous opportunity to make it easier for people to buy and sell goods. That's especially true when it comes to shopping apps, which should only continue to increase in... | Read more »
Human Anatomy Atlas 2017 Edition - Compl...
Human Anatomy Atlas 2017 Edition - Complete 3D Human Body 1.0.24 Device: iOS iPhone Category: Medical Price: $24.99, Version: 1.0.24 (iTunes) Description: | Read more »
Heroes of Normandie (Games)
Heroes of Normandie 1.5 Device: iOS Universal Category: Games Price: $14.99, Version: 1.5 (iTunes) Description: The game does not support iPhone 4s and below | Read more »
Why you should never power up Pokemon in...
There's no question that candy is dandy in Pokemon GO. You need big quantities of it to evolve your Pokemon, and when combined with stardust, it can be used to power up your favorite pocket monsters as well, making them more formidable for the gym... | Read more »
Webzen launches 3D MMORPG MU Origin on i...
Mu Origin is featured time and time again at the very top of App Stores in China, and within the top five worldwide top-grossing charts on Google Play.Its popularity in Korea and China, featuring more than 120 registered players in China and 6... | Read more »
Severed (Games)
Severed 1.0 Device: iOS Universal Category: Games Price: $5.99, Version: 1.0 (iTunes) Description: LAUNCH DISCOUNT ON NOW!! ENDS AUGUST 4! ==== Take control of a one-armed warrior named Sasha, wielding a living sword on her journey... | Read more »

Price Scanner via MacPrices.net

Second-Quarter Tablet Shipments Fell 4.8% –...
The latest report from the global market research firm TrendForce finds that worldwide tablet shipments for this second quarter totaled 33.54 million units, representing a quarterly drop of 4.8% and... Read more
Global Smartphone Sales Volumes Mark Second S...
According to preliminary results from the International Data Corporation (IDC) Worldwide Quarterly Mobile Phone Tracker, vendors shipped a total of 343.3 million smartphones worldwide in the second... Read more
Apple TVs on sale for $20-$40 off MSRP
Best Buy has 32GB and 64GB Apple TVs on sale for $20-$40 off MSRP on their online store. Choose free shipping or free local store pickup (if available). Sale prices for online orders only, in-store... Read more
Mac minis on sale for $50-$100 off MSRP
B&H Photo has Mac minis on sale for $50 off MSRP including free shipping plus NY sales tax only: - 1.4GHz Mac mini: $449 $50 off MSRP - 2.6GHz Mac mini: $649 $50 off MSRP - 2.8GHz Mac mini: $949... Read more
Clearance 2015 13-inch MacBook Airs available...
B&H Photo has clearance 2015 13″ MacBook Airs available for $300 off original MSRP. Shipping is free, and B&H charges NY sales tax only: - 13″ 1.6GHz/4GB/128GB MacBook Air (MJVE2LL/A): $799... Read more
Apple certified refurbished iPad mini 4s avai...
Apple has certified refurbished iPad mini 4s now available for up to $120 off the cost of new models. An Apple one-year warranty is included with each iPad, and shipping is free. The following models... Read more
Notebook Makers In No Rush To Adopt USB-C – R...
Digitimes’ Cage Chao and Joseph Tsai note that while the USB Type-C interface is enjoying growing popularity among smartphones and tablet makers, notebook and all-in-one (AIO) PC vendors (other than... Read more
iMacs on sale for up to $250 off MSRP
B&H Photo has 21″ and 27″ Apple iMacs on sale for up to $250 off MSRP including free shipping plus NY sales tax only: - 27″ 3.3GHz iMac 5K: $2049 $250 off MSRP - 27″ 3.2GHz/1TB Fusion iMac 5K: $... Read more
12-inch 1.1GHz Retina MacBooks on sale for up...
Amazon has 2016 12″ 1.1GHz/256GB Retina MacBooks on sale for up to $100 off MSRP including free shipping: - 12″ 1.1GHz Space Gray Retina MacBook: $1199 $100 off MSRP - 12″ 1.1GHz Silver Retina... Read more
Bare Bones Software Releases Free TextWrangle...
Bare Bones Software has announced the release and immediate availability of TextWrangler 5.5, a significant update to its powerful, free, general purpose text editor for Mac OS X. TextWrangler is a... Read more

Jobs Board

*Apple* Solutions Consultant - APPLE (United...
Job Summary As an Apple Solutions Consultant, you'll be the link between our future customers and our products. You'll showcase your entrepreneurial spirit as you Read more
Lead *Apple* Solutions Consultant - APPLE (...
Job Summary The Lead ASC is an Apple employee who serves as the Apple business manager and influencer across a number of Reseller locations. The Lead ASC's role Read more
*Apple* Retail - Multiple Positions, Charles...
Job Description:SalesSpecialist - Retail Customer Service and SalesTransform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
*Apple* Retail - Multiple Positions, Willow...
Job Description:SalesSpecialist - Retail Customer Service and SalesTransform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
*Apple* Evangelist - JAMF Software (United S...
The Apple Evangelist is responsible for building and cultivating strategic relationships with Apple 's small and mid-market business development field teams. This Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.