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

A beginner's guide to Spellbinders
Spellbinderslooks a heck of a lot like Clash Royale, but has an entirely different pace to it. As such, it can be difficult to adjust to. Just in case you've been playing way too much Clash Royale (and who hasn't), we've put together a bunch of... | Read more »
Camping With Grandpa (Education)
Camping With Grandpa 1.0 Device: iOS Universal Category: Education Price: $2.99, Version: 1.0 (iTunes) Description: | Read more »
Black Hole Joyrider (Games)
Black Hole Joyrider 1.0 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0 (iTunes) Description: Guide your spacecraft through the gravity well of a powerful black hole using only your retro-thrusters and dwindling fuel... | Read more »
My Koi (Games)
My Koi 1.0 Device: iOS iPhone Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: My Koi is a beautiful and relaxing fish pond app. Customise and name each fish. Feed them daily. Watch them grow. Collect new fish.... | Read more »
Never Gone (Games)
Never Gone 1.0.2 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0.2 (iTunes) Description: ###IMPPORTANT### Never Gone's HD art resources require devices with more than 1GB RAM, so please note that iPhone 4/4s, iPad 2/... | Read more »
INKS. (Games)
INKS. 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: From the makers of BAFTA-winning Lumino City comes INKS. INKS updates pinball for a new generation. It combines the joy of pinball with... | Read more »
How to maximise your profits in Bakery B...
Running a bakery can be an expensive venture. You’ll need to continuously upgrade your oven, your kitchen supplies, and even your ingredients to keep customers happy. Most of these renovations in Bakery Blitz cost a pretty penny, but we have a few... | Read more »
How to manage your time in Bakery Blitz
It can be tricky, especially when you risk burning your kitchen to the ground if you forget a cake in the oven, so make sure to use these time management tricks to keep your bakery running smoothly. Don’t collect the money right away [Read more] | Read more »
Model 15 (Music)
Model 15 1.0 Device: iOS iPhone Category: Music Price: $29.99, Version: 1.0 (iTunes) Description: The Moog Model 15 App is the first Moog modular synthesizer and synthesis educational tool created exclusively for iPad, iPhone and... | Read more »
How to deal with wind in Angry Birds Act...
Angry Birds Action! is a physics-based puzzler in which you're tasked with dragging and launching birds around an obstacle-littered field to achieve a set objective. It's simple enough at first, but when wind gets introduced things can get pretty... | Read more »

Price Scanner via MacPrices.net

Hybrid Tablets Meet Rising Demand for a Singl...
Rising demand for a new breed of hybrid tablets — 2 in 1 devices that function as either a laptop or a tablet — is shaking up the tablet market and contributing to a shift in the way owners are... Read more
Bausch + Lomb and IBM Collaborate on iPhone...
Global eye health company Bausch + Lomb, and IBM on Thursday announced a collaboration to develop the first app of its kind for iPhone and iPad for surgeons who perform cataract surgery. The... Read more
Apple & SAP Partner to Deliver New iOS Ap...
Apple and Walldorf, Germany based SAP have announced a partnership to revolutionize the mobile work experience for enterprise customers of all sizes, combining powerful native apps for iPhone and... Read more
New 12-inch 1.1GHz Rose Gold Retina MacBook o...
B&H Photo has the new 2016 12″ 1.1GHz/256GB Rose Gold Retina MacBook (sku MMGL2LL/A) on sale for $1199 including free shipping plus NY tax only. Their price is $100 off MSRP, and it’s the lowest... Read more
12-inch 128GB iPad Pros on sale for up to $10...
B&H Photo has 12″ 128GB WiFi iPad Pros on sale for up to $100 off MSRP, each including free shipping. B&H charges sales tax in NY only: - 12″ Space Gray 128GB WiFi iPad Pro: $899 $50 off MSRP... Read more
Global Tablet Sales Slump Continues, iPad’s F...
Another miserable showing for the global slate tablet category in calendar Q1/16, with global tablet shipments falling another 1ten percent to 46.5 million units during the according to Strategy... Read more
Revel Systems to Showcase iPad POS Platform w...
Revel Systems, specialists in iPad Point of Sale management solution for brick-and-mortar retail, food businesses and more, today announced that it will showcase its innovative iPad Point of Sale... Read more
13-inch 2.5GHz MacBook Pro on sale for $999,...
B&H Photo has the 13″ 2.5GHz MacBook Pro on sale for $999 including free shipping plus NY sales tax only. Their price is $100 off MSRP. Read more
Apple refurbished 2015 iMacs available for up...
Apple now has a full line of Certified Refurbished 2015 21″ & 27″ iMacs available for up to $350 off MSRP. Apple’s one-year warranty is standard, and shipping is free. The following models are... Read more
Indian Smartphone Market Grows Annually by 12...
India’s smartphone market grew by 12 percent year-over-year, with 24.4 million units shipping in Q1 2016. The top five vendors stayed the same, with Samsung in the lead, followed by Micromax, Intex... Read more

Jobs Board

*Apple* Support Technician II - Worldventure...
…global, fast growing member based travel company, is currently sourcing for an Apple Support Technician II to be based in our Plano headquarters. WorldVentures is Read more
*Apple* Retail - Multiple Positions (US) - A...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Restaurant Manager (Neighborhood Captain) - A...
…in every aspect of daily operation. WHY YOU'LL LIKE IT: You'll be the Big Apple . You'll solve problems. You'll get to show your ability to handle the stress and Read more
Automotive Sales Consultant - Apple Ford Linc...
…you. The best candidates are smart, technologically savvy and are customer focused. Apple Ford Lincoln Apple Valley is different, because: $30,000 annual salary Read more
Restaurant Manager (Neighborhood Captain) - A...
…in every aspect of daily operation. WHY YOU'LL LIKE IT: You'll be the Big Apple . You'll solve problems. You'll get to show your ability to handle the stress and Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.