Go OOP Young Man

January 4, 1998
by Alex Zavatone

This little trip through the realm of Multimedia development for me started because unlike many who those with a formal CS degree, I just didn't get all this computer malarky that "they" were feeding "us". Like many who are visually minded, I needed to see the end result or what was to be created, needed to know the "whys" of "why do I care about what you are teaching me" and the "whats" of "what will this junk allow me to accomplish." With this in mind and my history of being self taught through very linear basic programming, I hastily continued to putter down the road of linear programming.

Years pass. My philosophy is to recognise the people out there who know more than I do in one form or another and adapt what they know to my little school of thought while sharing what knowledge floats about in my own little chunk of synapses. Unfortunately, I'm pretty damn stubborn . But in those passing years, there have been several people who have helped push me to the path of good, tidy programming. Now I still wander (frequently mind you) but the more projects that are undertaken, the clearer the concept gets.

"What concept rocket boy?", says young Peter in the audience.

Well, linear programming as I had done it since a wee pup is just plain bad ugly nasty stuff. Object orientation is a methodology developed to help manage complex projects. Object Oriented Design (OOD) is the philosophy behind all that. It is not just "create a bunch of global objects that store all your stuff and access them when necessary" and honestly, I'm not completely there but hopefully, with each project, it's sinking in deeper and deeper. The deal here is such: this approach lets you write very efficient and manageable code. Handlers to perform specific tasks must exist within the object scripts that they are relevent to. For example, in my latest sprite server extension to the UI demo that I promise to write an article about, I found out that my current faux pas was to reference and query the window manager object by tearing apart its window lists and then getting the desired window object from the internal window list and then asking it for its location. Wrong wrong wrong. This inspired me to write a note to self that said "Note to self: do not do stupid things in the future when writing code." You see, there is this concept of accessors in OOD where you ask the appropriate handler within the object to do that nasty job for you. It's not more efficient but it results in cleaner code and is more manageable. So 5 lines of lingo used in many places were replaced with GetWindowState(gLayerObject, myWindowString). And thus an API was formed.

Well sort of.

See the API is the Applications Programming Interface and for this window layering object the GetWindowState me, myWindowString was the start of a mini API and a bunch of accessor routines to get the stuff that I needed to get for each window, its state, its index from name, its name from index, its location in the windowlist, etc. And how sweet it is. With this dynamic realization of the inclusion of "accessors" into the main object, I noticed the need for the same type of property modifier or "mutator" routines within the object as well. Now, the organization of OOD shows itself off in my little window manager. Suddenly, it becomes clear that when I need to find out a window's state, I ASK the routines that provide access to the states from within the object itself. When I need to change window states, I call the routines that provide access to do so that are within the object. Egads! My lingo gets more manageable, structured and simple It becomes obvious that it is the structure and protocol of communication that matters... not how many lines of code you use.

In retrospect, more things become obvious. I designed this window manager/sprite server by not fleshing out all the properties I would need to access and modify beforehand so it was actually designed by accident. A good first stab but a clumsy one at that. It works but it could work better. With this first stab completed, the lesson here is to design your object, spec out the properties required and figure out what will have to be modified and accessed. Place the routines to do so within the object script when you plan it out and your project will come together cleaner and faster.

Life's too short to write bad code.

A Director user since 1987, Alex (Zav) Zavatone has worked on the engineering teams for both Director and Shockwave, 4, 5, 6 and 7. Recent investigations find him developing foundation classes for Director with asynchronous process management and other life threatening activities. In its early days, he had something to do with this Internet thing known as "DOUG". A noted ne'erdowell, slacker and laggard, Mr. Zavatone is nonetheless is trusted by children, small animals and the elderly. In his spare time, Mr. Zavatone rehabilitates lame desert trout.