REALbasic University Resources: RBU: Glossary Defines common REALbasic programming terms   Archives Previously published columns Translations: Dutch Courtesy of Floris van Sandwijk   Japanese Courtesy of Kazuo Ishizuka   Chinese Courtesy of Dong Li   RBU Translation Guide Information on Translating RBU into other languages Books: Matt's Book (2nd Edition!) Ideal for experienced programmers   Erick's Book Best for beginning programmers Websites: Mother Ship The publisher of REALbasic   RB Webring Links to hundreds of REALbasic websites   RESExcellence Another REALbasic programming column   REALbasic Developer Magazine The premiere source for REALbasic instruction. REALbasic University is Sponsored by Make your Mac do what YOU want it to. Create games, utilities, cool Mac OS X tricks. Download REALbasic now and create your own software.

REALbasic University: Column 096

OOP University: Part Twenty

Last week we reviewed some key object-oriented concepts; what we're going to do now is explore more OO ideas, especially in connection with how they work in practical applications. We'll do this over the next few lessons and I hope the different approach helps your understanding.

OOP and Program Design

This particular RBU direction was partially inspired by an email I received from Markus Winter in New Zealand. He writes:

Hi Marc,

I stumbled over another "problem" that most beginners will encounter sooner or later, and one which makes starting to program so hard - I have no clue what I'm doing wrong.

Yep, that's it.

I have a faint idea of what a program is or should be, but I don't know which parts I'm missing out on.

It's fairly easy in REALBasic to write a little single-task program, but as soon as I imagine something more complex I hit a brick wall. As an example I'm currently trying to give user feedback on a little program that I made - e.g. pop up a window with a progress bar and a cancel button. Turns out that to get the cancel button working I need to run my program with threads. Which now means I need to go back and possibly rewrite everything. Which makes me wonder about the "design" of the program. And what other designs I'm missing out on: multiple windows? Preferences?

So it might be an idea to as part of the OOP include a lecture on program design, or maybe even program an application frame which deals with all these pesky issues ...

Best Regards

Markus

P.S. Still enjoying your lectures - pity the "mail alerts" I subscribed to don't work ...

Markus has an excellent point: in a simple program, the task is so linear that it's often relatively easy for a beginner to stumble to a solution. But as soon as a program becomes complicated, involving multiple parts that talk to each other, a beginner can feel swamped.

What also makes these kinds of programs difficult is that it's tough to test the program when it's unfinished, so a beginner invests a lot of energy into a particular methology, eventually figures out that the design is wrong, but doesn't want to start over, and kluges together an awkward fix. Thereafter the program is difficult to maintain and fix bugs, and the programmer begins to dread working on it.

I'm not sure there's a true solution to this problem -- the temptation to program without designing is extremely strong and only experience teaches you not to succumb to it -- but the bottom line is that "measure twice, cut once" will always benefit you in the long run.

But part of the reason beginning programmers don't like to "waste" time designing their programs is because they don't understand the design phase of programming. The coding phase is more linear and easier to comprehend: start here, end there. Design is all open-ended, with lots of confusing options. Do it with method A, method B, or method C.

Throw object-oriented programming into the mix, where you need to design classes and interactive objects, and programming is starting to sound like work!

The truth is that design can be one of the most fun things about programming. Look at it this way: there are no limits. During the design phase, you can do anything. So explore. Brainstorm. Invent. Be creative. Think. Plan. Anticipate.

There are three basic steps to program design:

1. Define the problem.
2. Brainstorm solutions.
3. Evaluate the solutions.

Each of those are more involved than they sound. They may each have dozens of sub-steps.

The first one, defining the problem, sounds easy. But remember, we're talking about a computer here. You must describe the problem in a way that a computer would see it. It is often during this step that you learn a great deal about what you really want to do: many times it turns out to be different from what you thought you wanted.

The RBlog Example Project

Let's explore this with a fictitious example project. Let's say you're writing a Blogger-type weblog program. This program maintains a database of user entries, each stored by date and time. When the user presses the "Publish" button, the program generates the website, including links to archived entries and more, and uploads all the HTML files and graphics to the user's website. We'll assume this could take a little time, and like Markus' situation, we'll need a progress display with a cancel button.

So what are our problems? In this example, there are many. In brief, here's what we'll need (in no particular order):

• A database storage system (read/add/delete data).
• Methods to sort, search, and organize the data (blog entries).
• Methods to translate the data to HTML.
• A user interface for adding and modifying data.
• User preference settings to control the appearance of the weblog.

As you can see, the "problem" of handling the progress display doesn't even show up here: we aren't detailed enough in our list of problems. But we'll get to that eventually.

Once you've got the problem figured out, you need to generate some solutions. Don't go with your first instinct. It might be correct, but it might not. Take a few minutes to think about the problem and come up with some alternative approaches to solving it.

The most important aspect of any program is the data structure you select. This has severe consequences to everything that the program does. You need to pick a data structure that fits the needs of the program you are writing.

For example, an email program is basically a database of text snippets. But the way a user operates an email program -- opening multiple emails at once, archiving some into folders, searching through the entire archive for a phone number, etc. -- means that your database had better be fast. After all, who wants an email program that takes forever to display the contents of a folder?

In a different example, let's say you're writing a 3-dimensional multiuser Internet game. Games generally don't have that much dynamic data to manipulate (a map, location, bad guys, lists of weapons, health ratings, score, etc.) so you might initially think a game's data structure really isn't that important. But this is a networked game -- that means you have to send certain pieces of data back and forth around the network so all gamers are in sync. That means you want to plan your data structure carefully: you want it compact, so there's not much data to transfer, and you want your program to be able to decode and use the data quickly.

Think about scale: the needs of a program with 200 pieces of data are very different from a program that will store millions (the difference between a personal accounting program and an accounting program for a Fortune 500 company).

Plan for the habits of your users. How will they use the program? For example, you could decide that it would be great if your program saved its data in portable XML format. But XML is a text-heavy format: with large amounts of data, saving it to XML could be time-consuming. If your users are the kind who save their work regularly, even a few extra seconds of saving time could annoy users.

Think about the kinds of things your program will need to do with the data. Will the data be changed regularly? Will it be loaded and reviewed often? Will the data need to be sorted, and if so, how often and how complex a sort? Will the program be required to search out pieces of data? What kinds of searches and how often?

Let's look at these issues with RBlog, our example weblog project. Weblogs typically deal with information (primarily text) in discrete lumps (entries). Each entry has a date and time of when it was written. Like an email, an entry might have certain standard parts, such as a title, category, etc. The text may include HTML formatting and inline pictures.

A weblog site typically has multiple areas: a main page, where current postings are listed in reverse chronological order (newest to oldest); an archive page, with links to posts archived (usually) by month and year; month pages, which include all the posts for a particular month. Some sites also offer archived posts alphabetical by subject. A blog program needs to generate all those pages automatically, but those kinds of pages change every time a new entry is added.

Most blogs are updated regularly, perhaps several times per week, daily, or even several times a day. Typically there are only a few entries per day. A blog that's been around for several years will contain thousands of entries.

The conclusion? Our data structure needs to be quickly searchable by date/time, title, and subject. We won't be dealing with a huge number of entries -- a ten-year archive of three posts per day is only eleven thousand items -- so our sorting and searching system does not have to be too complicated. We value features and ease-of-use over raw speed.

However, as our program will be generating lists of archived entries, organized by both subject and date, we do need an efficient retrieval system since every time an entry is added, part of the archived material will have to be updated.

Finally, while 11,000 items (our estimated high amount) might not be that many for a sort, it could be a lot of data to be reading and writing (if each entry is 1K of data, that would be eleven megabytes). We need to ensure that our system doesn't take too long to save the data file. Our data file format will also need to be able to store pictures as well as text data.

As you can see, we've established several key requirements of our data structure. Next we've got to figure out some ideas of how that data structure might be developed. How do objects fit into that structure?

Your homework is to come up with at least three completely different potential data structures for RBlog. I stress the "completely different" because I want you to work at seeing how radical you can be. Next time I'll reveal my approaches, and we'll do step three, where we break those apart and attempt to decide which approach is the best.

Next Week

We continue learning how to design object-oriented programs.

Letters

It appears people are still strugging with the concept of global variables. This week I received this plea from Corey Crossman, who writes:

How do I get a global variable? I followed your lesson for globals in lesson 19 I think... but it doesnt work!

Ok here's what I'm trying to do. I have an editfield (editfield3) in window1 (called starting)... I want that text in window2 in an editfield (editfield1) in the window connecting... now how would I go about doing this? I also would like to recall this variable for later.

Answering my question ASAP would be appreciated! I need help! Ahh brain hurts.

Cert

Well, Corey, here it is in a few simple steps.

1. Add a module to your project (on the File menu and choose the "New Module" option).
2. Open this module by double-clicking on it.
3. Add a property to this module (go to the Edit menu and choose "New Property..."). It is recommended you name globals in a consistent way so you can tell they are global. I precede mine with a lowercase "g" as in gTheScore as integer.

In your case, since you want to remember the contents of an editField, you'll need a string variable (i.e. gTheText as string). Once declared as a global (by being in a module) you can access this variable anywhere in your program. So in Window1 you could write:

  
  gTheText = editField3.text 
   

to save the text for later use elsewhere. You could move that text in the other window (window2) by saying:

  
  window2.editField1.text = gTheText 
   

BTW, I'm not sure which lesson you were referring to, but I answer letters about global variables in RBU 16 and 53, and you can use this Google search to find other mentions in RBU.

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

.