macdevcenter.com
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

With REALbasic, Object-Oriented Programming is Easy

by Matt Neuburg
10/23/2001

What's object-oriented programming (OOP)? Whatever it is, it's clearly the future. Widely used professional programming languages like C++ and Java are object oriented. Your bookstore's shelves are filled with books on object-oriented programming; Amazon.com's Object-Oriented Design page lists over 1,000 of them.

Related Reading

REALBasic: TDG
By Matt Neuburg

If you've never programmed before, OOP may seem like an unfair extra hurdle. But have no fear: REALbasic is here to help. In an earlier article, Teaching Kids to Program with REALbasic, I talked about why REALbasic is a great way to learn to program. Well, REALbasic is also a great way to learn object-oriented programming. I'm a case in point. I tried to learn C++ for years, but just couldn't wrap my mind around it. After learning REALbasic, I went back to C++ and found I understood it. REALbasic had taught me the object-oriented programming concepts that had previously eluded me.

OOP is not something to be afraid of. Object orientation makes programming easier, not harder; and this is particularly true in REALbasic, where objects themselves are so easy to use and their benefits are so immediately apparent.

What Are Objects?

Here are five ways of grasping what objects are and how they make your life easier when you're programming.

  1. Objects are a way of organizing your program.

    Your program is text (or "code," in programmer talk) and all that text has to go somewhere. If it all went into one long continuous text file, you could never find any of it; it would be like a book that just goes on and on, and you'd always be flipping through it searching for things. Objects give your code structure; they are like the chapters and sections of your book.

    For example, Figure 1 shows the Project Window for the Tic-Tac-Toe game developed in the appendix of my REALbasic book:

    Figure 1
    Figure 1

    Basically, the things listed in this window are the program's objects. You can probably even guess where some of the code lives. For example, in Tic-Tac-Toe you need to know whether any row contains three of the same piece because if it does the game is over. Where do you suppose I've put the code for finding this out? In the Row object, of course!

    With REALbasic, to see an object's code, you just double-click its listing in the Project Window. Double-click the Row object listing, and there's the ThreeInARow code. Figure 2 shows how REALbasic helps your code stay clear and organized by physically packaging the code for an object in one place.

    Figure 2
    Figure 2

  2. Objects are the actors.

    In a REALbasic program, the only way anything happens at all is because a message is sent to an object telling it to do something. Thus, you can envision a running program as a series of messages being sent from object to object.

    For instance, Figure 3 shows a simple Hello World program consisting of a button and a text field:

    Figure 3.
    Figure 3

    When the user presses the button, the text field reads "Hello, world!", as shown in Figure 4.

    Figure 4.
    Figure 4

    Figure 5 shows the code that makes this happen. It's the only code in the program.

    Figure 5
    Figure 5

    The button and the text field are a PushButton object and an EditField object, called PushButton1 and TheEditField. When the user presses the button, REALbasic's application framework sends the Action message to PushButton1, telling it to run its Action code--that's the code you see here. The Action code sends a message to TheEditField telling it to set its Text to the string "Hello, world!" The linguistic syntax for this is called dot notation: We have the name of the object (TheEditField), a dot, and then what we want the object to do. This code is like saying: Hey, TheEditField! Set your Text to "Hello, world!"


    Visit mac.oreilly.com for a complete list of O'Reilly's books on Apple technologies.


    It doesn't take much code in REALbasic to make things happen, does it? The reason is that without you having to write any code at all, REALbasic is already stocked with objects that know how to do useful things. An EditField automatically displays its own Text. So, we set its Text and presto, that's what appears in the window! Much of REALbasic's power and ease lie in "smart" built-in objects like this.

  3. Objects are your program's entities.
     After learning REALbasic, I went back to C++ and found I understood it; REALbasic had taught me the object-oriented programming concepts that had previously eluded me.

    Human beings naturally perceive the world as made up of things. With objects, you get to pretend that your program is made up of "things" too! REALbasic gives you a head start, thanks to its repertoire of built-in objects. Mostly, these are the "things" that make up your program's user interface. For example, in our Hello World program, the PushButton is an object, the EditField is an object, the window is an object, and even the Quit menu item in the File menu is an object.

    You can also define your own objects. Deciding what objects to define is a challenge, but it's fun too. It's like creating your own little universe! In the Tic-Tac-Toe game, just about all the objects listed in the Project Window are objects I defined myself. And you can see that these are based on aspects of a real Tic-Tac-Toe game: an X, an O, a Space (a place where one can play an X or an O), a Row (three Spaces in a straight line), a Game with a HumanPlayer and a ComputerPlayer, and so forth.

  4. Objects make your program more legible.

    This comes from having objects with well-chosen names; the names of things show clearly what you're doing.

    Even without knowing REALbasic you can get a sense of this. For example, Figure 6 shows the code from my Tic-Tac-Toe game where the computer decides where to play. First, the computer looks at every row to see if it's got two in a row of its own piece. If so, it plays in the empty space, to win. Then, it looks at every row to see if it's got two in a row of the opponent's piece. If so, it plays in the empty space, to block the opponent's win. Otherwise, it just plays randomly. The REALbasic code doesn't quite say this in plain English, of course, but it almost does! Objects and dot notation make that possible.

    Figure 6
    Figure 6

  5. Objects are reusable.

    Often, you'll make objects that are useful in more than one context. It might be an interface widget that lets the user navigate files and folders on the hard disk, or it might be something quite abstract, like an object that knows how to perform SHA1 hash-encoding (whatever that is!). The point is, once you've made such an object, you can use it in any REALbasic program you write. Just drag the object from the Project Window into the Finder. Now the object lives on its own, independent of any program. Later, if you write some other program where you want to use that object, just drag it from the Finder into that program.

Classes and Instances

Objects aren't just reusable between different programs; they're reusable in the same program. Look at the example in Figure 7:

Figure 7
Figure 7

Here we see a little game with three targets. The targets are marching rightward across the window, and the user is supposed to shoot at them. You can also see the Target object's Draw code. Basically this just draws three concentric colored circles. Now, although you see three targets, there is just one piece of Draw code. All the targets in the program draw themselves the same way because they all use this same code. In technical OOP talk, we say that all the visible targets are instances of the Target class.

Clearly, this saves the programmer from repetition. Also, it makes sweeping changes easy. In Figure 8, I've changed just one number in one line of the Draw code--can you find it? As a result, all the targets now draw themselves in a new way.

Figure 8
Figure 8

Inheritance

Objects are reusable in yet another way: They can be customized. The programmer can make an object that's based on some other object except for some particular difference or differences. This is called inheritance because the customized object inherits the original object's features. In REALbasic this is particularly useful because you can customize objects that aren't yours.

To see what I mean, let's think about the built-in EditField class again. We already saw that it knows how to display its own Text automatically; and it has other powers too. The user can type into an EditField, scroll an EditField, and copy from an EditField. Great. But now let's be greedy. Suppose you want an EditField that knows how to do all those things plus a little bit more.

For example, an EditField does not automatically know how to respond to the Select All menu item. So let's add that knowledge. First, create an object (let's call it SelectAllEditField), and use the Properties Window to specify that its 'Super' is EditField (see Figure 9). This means it's an EditField plus whatever we now add to it.

Figure 9
Figure 9

To prove that SelectAllEditField is an EditField, drag one from the Project Window into the program window, as shown in Figure 10:

Figure 10
Figure 10

Sure enough, you wind up with an EditField in the window (Figure 11).

Figure 11
Figure 11

In other words, SelectAllEditField is thus far indistinguishable from the built-in EditField--except that you can add your own code to it. And you already know how to do so: Double-click the SelectAllEditField listing in the Project Window. This opens the code window where you can put the code that says what should happen when the user chooses the Select All menu item (Figure 12).

Figure 12
Figure 12

It works! Now a user can choose the Select All menu item to select all of the text in the field, as shown in Figure 13.

Figure 13
Figure 13

Remember, the rule about classes and instances means that this code is very powerful. You can put as many SelectAllEditFields into your program as you want--they will each respond correctly to the Select All menu item.


Teaching Kids to Program with REALbasic--Teaching a few programming basics to kids will show them what's really going on behind the monitor, and REALbasic is a great tool for the task. Matt Neuburg has put together some fun programming projects that children can grasp.


Conclusion

This isn't all there is to know about objects and object-oriented programming, but it's enough to show that there's a good reason why object-oriented programming is so widely used. It's because objects are helpful, useful, and powerful. Objects are also fun, and in REALbasic they're part of what makes programming fun.

My book, REALbasic: The Definitive Guide, 2nd Edition, assumes you've never programmed before. Nevertheless, in the course of teaching you the language, it also teaches you about object-oriented programming, very early on. (For an online preview of the details, you can view Sample Chapter 3 and Sample Chapter 4, the two main chapters about object orientation in REALbasic.)

The reason my book takes this approach is that in REALbasic it's impossible not to do object-oriented programming. Objects in REALbasic aren't some kind of icing on the cake; they aren't an extra, higher level of programming. They are built right in to everything you do: They're a basic part of the language, and they're a basic part of the interface you're working in as you program with REALbasic. And the integration of objects with the language and the interface is an important part of why it's possible to write useful programs so quickly in REALbasic.


Matt Neuburg started programming computers in 1968, when he was 14 years old, as a member of a literally underground high school club that met once a week to do time-sharing on a bank of PDP-10s by way of primitive teletype machines. He also occasionally used Princeton University's IBM-360/67, but gave it up in frustration when one day he dropped his punch cards. He majored in Greek at Swarthmore College and received his Ph.D. from Cornell University in 1981, writing his doctoral dissertation (about Aeschylus) on a mainframe. He proceeded to teach classical languages, literature, and culture at many well-known institutions of higher learning, most of which now disavow knowledge of his existence, and to publish numerous scholarly articles unlikely to interest anyone.

Meanwhile he obtained an Apple IIc and became hopelessly hooked on computers again, migrating to a Macintosh in 1990. He wrote some educational and utility freeware, became an early regular contributor to the online journal TidBITS, and in 1995 left academe to edit MacTech Magazine. In August 1996 he became a freelancer, which means he has been looking for work ever since. Matt is the author of two O'Reilly books, REALbasic: The Definitive Guide, 2nd Edition and Frontier: The Definitive Guide.


O'Reilly & Associates recently released (September 2001) REALbasic: The Definitive Guide, 2nd Edition.

Matt Neuburg is the author of O'Reilly's "AppleScript: The Definitive Guide," "REALbasic: The Definitive Guide," and "Frontier: The Definitive Guide," and is a former editor of MacTech magazine.


Return to: mac.oreilly.com