OOP University: Part One

Last week I announced I planned a new series of RBU columns focusing on Object-Oriented Programming (OOP). I'm calling this series "OOP University." I've already received some positive feedback (see today's Letter's section) on this decision.

We'll see how these people feel after I'm finished. I certainly don't claim to be an OOP expert, and I'm sure there are "textbook" aspects of OOP that I don't know, but I think I can at least get everyone introduced into basic OOP concepts. Beyond that, there are tons of books on advanced aspects of OOP, and once you understand the basics, those concepts should be easily adapatible to REALbasic.

So let's get started!

Introduction

In talking with experienced programmers learning to use the "object-oriented" REALbasic for the first time, I've noticed something interesting. There are two concepts key to modern programming: objects and event-driven applications. These are not the same thing at all, yet they overlap to an extent, and people with traditional programming experience often confuse the two.

To learn modern programming, it is critical you understand the difference between these two concepts. Each presents unusual challenges and problems to the traditional programmer, and if you aren't firmly grounded in the differences, you won't know how to solve the problems you encounter.

The first thing I'm going to do is explain, in detail, these concepts. Modern programming will require a new mindset for you to adapt. That's not a bad thing, though it can be challenging and unnerving.

So relax, keep an open mind, and don't worry if you don't understand things instantly -- it will come, I promise you.

Modal Programming

Traditional programming, which, for the sake of simplicity, we'll say is most programming of the 80's and earlier, was extremely linear. That is, it had a start point, a clear middle, and an obvious ending. A program was written very similar to the way its algorithm appeared: step 1, step 2, step 3, step 4, done.

Those programs were what we call modal: modal simply means the program has various "modes" and the user's actions are limited within each mode. Let me give you a couple examples.

Let's say it's 1982 and you're writing a word processor. Besides the fact that word processors back then were a lot simpler and had hardly any of the features of today's mammoth programs, let's look at the way you might write the program.

We'll start with an opening menu: here the user can create a new file, open an existing file, print a file, or quit. That's is the Opening Menu Mode: only those four commands are possible and nothing else.

Opening Menu Mode:
   - New File
   - Open File
   - Print File
   - Quit

Our code for the Opening Menu Mode is simple enough. If the user chooses to open an existing file, you ask them for the name and they type it in. If the file exists, you open it and pass the text to the Editing Mode, otherwise you indicate an error. Printing is similar, except instead of going to Editing Mode, you go to Print Mode. The New File command asks the user for a new filename and if that file doesn't exist, takes the user to the Editing Mode with a blank document. Quit just quits. (Note there's no need to confirm saving a potentially unsaved document, since no document can be open in Opening Menu Mode -- see how simple life used to be?)

Print Mode isn't too difficult either: we present a screen with some simple printing options (select a page range, page numbering on/off, header and footer on/off, maybe a setting for the print quality), and then we print the document. When we're done, it's back to Opening Menu Mode.

The most complex mode is Editing Mode. Editing Mode is where the user can type in text. There's a number of complicated things we must do here. We must handle the movement of the text cursor (moved by arrow keys -- remember, this is pre-mouse), accept key presses, handle the backspace key (delete the character to the left of the cursor), etc.

Within Editing Mode there are a few special commands to help the user. For simplicity, we'll limit these to a select few: Jump to Start, Jump to End, Flush Left, Center Text, Justifed, Word Count, Check Spelling, Save, and Exit.

Those commands are all activated by pressing a special key: in the old days of DOS this was usually the Control key. Technically, once the Control key is pressed, we're in another mode: Control Key Mode. Control Key Mode just watches to see what keys were pressed and if they match any commands you've established. For instance, Control-S (^S) might be the Save command.

Without the Control key down, Editing Mode just allows the user to type. In that mode, all you have to handle is the user typing. In Control Key Mode, you must examine the key(s) the user pressed and pass control of the program to the appropriate module. For instance, if the user chose Check Spelling, you'd need to go to Check Spelling Mode.

In Check Spelling Mode, none of the other commands are valid. We're in another mode and all other commands are disabled. In Check Spelling Mode we have these commands available:

Check Spelling Mode
  - Skip Word (spelled correctly)
  - Add Word to Dictionary
  - Select Replacement from Suggestion List
  - Type in Replacement
  - Exit

Once again, the user's options are extremely limited. From a programmer's perspective, this is good: we don't have to worry about the user doing something unexpected, like renaming the file we're editing. (Remember, back in 1982, personal computer operating systems were modal [one thing at a time] just like programs.)

Despite the various modes, the code for this word processor would generally be a single, very long file. (Some languages would allow you link various files into one larger program, and you could call routines that existed in a separate file, but the linear principle was still the same.)

Your code would general consist of subroutines, with a subroutine for each mode. For instance, this simple routine could be Open Menu Mode:

procedure open_menu;

var k: char;

begin {open_menu}

  repeat
    k = readKey;
    if k := "N" then
      new_file;
    end if;

    if k = "O" then
      open_file;
    end if;

    if k = "P" then
      print_file;
    end if;
  until k = "E";

end; {open_menu}

The above is written in Pascal (at least the best I can remember ;-) -- stuff in braces {} are comments. The "readKey" function checks to see if a key has been pressed on the keyboard and assigns it to the variable "k". The new_file, open_file, print_file are, presumably, other subroutines you've written to handle those various modes.

As you can see, the coding is fairly simple and clear: but that's because we limit the user severely. The computer is always in unique "modes" where only a few commands are possible. That makes the programmer's work simpler, but it often frustrates the user. The Macintosh changed all that.

The Macintosh, you see, is "event-driven."

What's that? Well, that I'll explain in our next lesson.

Next Week

"OOP University" continues with an explanation of "event-driven" programming.

Letters

These are some nice letters I received from those excited about this new OOP series. First, from Ray Dosh:

Marc,

Somewhere, I read that someone recommended a particular book for learning object-oriented programming. I picked up a copy and, even though I haven't finished it yet, I can heartily recommend it myself. The Object-Oriented Thought Process (by Matt Weisfeld, Sams Publishing, 2000) is a highly understandable introduction to O-O programming techniques and does not depend on any prior programming experience or knowledge. Some examples are given in Java but knowledge of Java is not required. The book also serves as an introduction to Unified Modeling Language (UML) which may be useful to your readers (I haven't tried it yet but I hope to soon).

Thanks, Ray! Sounds like a good read. Having learned OOP via osmosis, I just ordered mine from Amazon. If appropriate, I might write a review for RBU.

Next, a note from Craig Brown:

Good on you, Marc! I'll be reading the coming installments on OOP. I'm in about the same boat as Ben. As I may have told you in the past, most of my programming experience was in a proprietary language on NCR mainframe computers. I was really good at it. Did it for about 25 years. I've been noodling around with RB for a couple of years now and have written some usable programs, but I still feel like a neophyte when it comes to OOP.

The second letter from Ben that you printed in this week's RBU column puts me even more in his camp. I have a program I've worked on for a long time (in my spare time) whose purpose is to help me create acrostic puzzles. I got it to the point I could draw the blank puzzle on a canvas. Cool! When I delved into trying to print it I felt like I'd run into a brick wall. It still doesn't print. My inability may or may not have anything to do with my not knowing OOP, but we'll see.

Anyhow I am quite pleased to see you preparing to unlock the mysteries of OOP to traditional programmers.

Hope you have a good Thanksgiving day.

Thanks!
Craig Brown

Thanks for the feedback, Craig! Be sure to let me know if the series proves helpful.

Next, Joe Cabrera writes:

Hi Marc,

AMEN! This is exactly what I need to check out. I find that I learn best by example, with the bits and pieces broken down along the way. I have the general idea of OOP down in my head, it's the implementing that's bogging me down. If you can bust that icedam in my head so I can jump in with my coding I'd be most eternally grateful.

I really should have written sooner, though. If readers don't pipe up, how will you ever know what needs addressing most? I think part of me was afraid this was way too basic a thing for your intended audience. When my eyes glazed over during the entire RBU Pyramid thing, I thought maybe my needs were a little too basic.

But thanks again for all your work -- I check out RBU every week.

Regards,
joe cabrera

While it's tough keeping RBU with a balance for beginning and mature programmers, RBU's slant is definitely toward those just starting out with REALbasic. RBU Pyramid was a large, complex project, and while I'm glad I did it (now that it's finished it's a unique resource and teaches a lot of techniques), I think something that long is a bit much for this format. I'm focusing on shorter lessons that teach one or two techniques. Hopefully the OOP series will be just what the doctor ordered.

Speaking of doctors (sorry, I couldn't resist), the next letter is from Dr Alexander G Bennett in Australia:

Dear Marc,

I was reading your most recent RBU #76 - I've been away for a time - and I thought I would briefly share the two fundamental issues for me in OOP and why I like RB so much.

You may recall that I wrote some time ago about a Medical Records and Billing System that I was porting to RB and PostgreSQL from 4D. It is well under way now.

Fundamental #1:

Organisation: the ability to organise and structure the location and access to code using the nested folder system - clunky as it is - has been crucial to steadily building a very complex application.

Fundamental #2:

Classes: these are just the most wonderful invention

the ability to pass them all over the place as parameters

to compartentalise related but different bits of data thus building tight code

to build wrappers for things that RB does not do natively

most of all: the ability to write code but once, use it everywhere and update it easily these are truly magical things

RB is complex - perhaps unnecessarily so to the programmer sometimes - and it is daunting to learn but the rewards are great. Like any programming environment there are lots of "gotchas" and idiosyncratic nasties, and the IDE is bloody unstable. But for all that, RB is the most fun of any of the several programming environments I have used.

Thank you for your great work with the magazine to which I have just subscribed and RBU. These lectures on OOP will interest me greatly.

Regards,

Alexander

Thanks, Alexander. You've got a great attitude. For those of us who've got a little bit of programming background, REALbasic seems amazing, but you're correct that it can always get better (and thanks to REAL Software, it does).

One of the things I like about REALbasic is that it doesn't force you to use OOP: you can just dive in without having to learn a lot new concepts. Of course there's a lot of OOP behind the scenes, and there's an OOP foundation if you want to take advantage of it, but you can do that gradually. With every new program I write I incorporate more and more OOP techniques. Eventually, maybe, I'll have a proper OOP application!

Thanks for all the letters, everyone. I hope you benefit from the OOP series and I plan on learning a lot myself in the process!

About the Column
REALbasic University is a weekly instructional column on programming with REALbasic and is brought to you by REALbasic Developer, the magazine for REALbasic programmers.

Each week we answer select reader questions, and we're always open to ideas for future columns. Send your questions to . (Keep your questions simple and specific. General queries like "How do I write my own web browser?" will be neglected.) Your question won't be answered immediately, but will be answered in a future column. (If you don't want your correspondence published, just be sure to indicate that when you write. Otherwise it's fair game.)

About the Author
is an author, philosopher, graphic designer, photographer, film director, soccer fanatic, and programmer (among other things). He writes for MacOpinion, runs his own software company, Stone Table Software, which sells the revolutionary Z-Write word processor, and is Publisher and Editor of REALbasic Developer. He lives in Northern California with his cats, Mischief and Mayhem, and is rapidly running out of free time.

See the REALbasic University Archives