ActionScript 3.0 Design Patterns/OOP/Principles and Algorithms: The Forest and Trees of Programming

I’ve been working on documentation, and I began thinking about the concepts of design patterns/OOP/principles and algorithms as the forest and trees, respectively. The documentation involves Server Side ActionScript (SSAS, which is ActionScript 1.0) and good old ActionScript 3.0 on the client side. (In this context, client refers to the client making requests from the server, and not Client as a class that makes requests from other classes in a design pattern.)

In previous posts I’ve admitted to being an algorithm junkie, and for the last several days that’s exactly the habit I’ve been feeding. Since I was documenting SSAS—ActionScript 1.0— which has no user classes or typed data, I can say with a straight face that I really didn’t have a lot of choice. However, the client side work with AS 3.0 could have been more OOP-like and maybe a little Strategy pattern could have been used just to get everyone off on the right foot.

Let’s face it, though, if someone is trying to learn how to work with a class, no matter what version of ActionScript, they don’t need it to be couched in a design pattern or OOP. I’ll often see some convoluted program that the documenter hopes to show off his/her programming acumen while explaining how to use a particular class with its properties, methods and events. Eventually, the long-suffering reader may finally (if ever) get what the documentation is trying to get across, but an easier route would have been to create a straightforward example the user can use. The developer is either going to use it in an OOP/DP context or not regardless of an example’s structure.

Clear and Simple are not the Same

In working with the documentation, I created a big fat string that contained data from a Web service and was sent from the server to a callback function on the client side. Once the client got the data, it had to be taken apart and broken into elements to be placed into an array. Since I was making the example for documentation, I wanted it to be fairly simple. The Web service delivered data in the form of a series of strings, and these small strings were concatenated into a single large string. The concatenated string kept the chunks of information from the Web service separated with tildes (~). The server-side program sent the concatenated string to the client. So all I had to do was to split up the string into array elements and run out the data to a text object using the tile (~) to re-establish the original categories on the client. I used the following ActionScript 3.0 method:

1
2
3
4
5
6
7
8
9
10
11
12

//The webser parameter is a concatenated string from
//Web service sent from Flash Media Interactive Server
 
private function serviceReport(webser:String)
{
	var serviceArray:Array=webser.split(/~/);
	txtArea.text = "";
	for(var serInfo in serviceArray)
	{
		txtArea.appendText(serviceArray[serInfo]+"\n");
	}
}

In and of itself, the method and accompanying algorithm are no great shakes, but since I don’t spend a lot of time breaking down big strings into array elements, I had to re-learn how to do it. Obviously I could have strong-armed it by iterating through the string and pushing chunks of it onto the array. That would have gotten it done, but I remember when I whined loudly to Adobe to include Regular Expressions in ActionScript. Well, they did and it wouldn’t be right of me to not use them. (Perl programmers write symphonies in Regular Expressions, but a lot of us mere mortals have to re-educate ourselves in the damned things every time we use them.) Then I dug up the split method which I had “remembered” as having something to do with arrays; however, it turns out the method is actually a string method to break up strings into array elements. What’s more, they use Regular Expressions in their parameters; so all I had to do was to check out String.split()in the String class and use a Regular Expression to crunch the big string into array elements.

For some reason, the person writing the documentation decided to show off some slick tricks using Regular Expressions. None of the “tricks” did anything other than generate confusion because the results of the Regular Expressions did absolutely nothing of use. So, I decided on a hunch to use the regular expression, “/~/” as the split() parameter, and it worked fine—no thanks to the documentation.

My intention was not to create an example of how to turn a string into array elements but rather how to use the SSAS WebService class in ActionScript 1.0 to get information from a web service and display it in a client-side object. Passing data from an ActionScript 1.0 object to an ActionScript 3.0 object involves a series of steps that must be handled in a certain way, and sometimes these steps are a little tricky—especially when using web services from remote servers and then passing them through an open socket server such as Flash Media Interactive Server and then back to a display object generated by Flex or Flash.

In explaining the process if it is so simple that the developer cannot use it in a program, it’s useless.

If I describe a nail and show a picture of a nail I’ve provided a clear and simple idea of a nail, but I have not explained carpentry.

This is what I mean when I say that sometimes simple is not the same as clear. Likewise, a pithy set of examples can be as confusing as something long and convoluted— check out Rube Goldberg to visualize convolution. (Oddly, Goldberg’s creations have a clean water clarity from the starting point to the end result—convoluted as they may be.)

The examples of working with class procedures are the trees of programming in that they are algorithms encapsulated in methods. However, the procedures for these algorithms sound more like forests—or even dense jungles—in some cases. With the busy programmer or student of programming (which to some extent we all are and will continue to be), how do we ever get to OOP or Design Patterns when dealing with some fairly complex algorithms in the first place?

Levels of Abstractions

One image of separating levels of abstractions is with a single head of cattle and a herd. Further arranging the cattle, we can imagine the cattle organized in corrals. From space, the corrals look like specks, and several corrals organized into a ranch may appear as a dot. Figure 1 gives you an idea—the picture from space shows part of Argentina’s cattle country, and some of those pixels might be corrals or ranches but the dark areas are lakes.

Figure 1: All Levels of Abstractions have Concrete Elements

A single cow (named Evita Guevara) is different from all other cows in the herd, but she is part of the herd. We can differentiate Herd A from Herd B by size, color, location or any other criteria we want. However, Cow A from Herd A may also sometimes hang out with Herd B; so Cow A in Herd A is identical to Cow A in Herd B. Or is it? When Cow A is in Herd B we can say that the character of Herd B changes but so too does Cow A because of a different Herd? Of course we can. In the same way that the same algorithm can be used in a variety of different classes, classes within a design pattern or a design patterns within a framework. Because of the context it’s in, it is transformed, but at the same time it transforms and defines the context.

Going the other way, I find that quantum computing to be informative. Some years ago I was reading about a French engineer who had successfully created a computing unit in nanotechnology where each bit was made up of electrons in three states—on (excited), off (unexcited) and both (simultaneously excited and unexcited). Thus, quantum bits (called qubits) can be 0 or 1, or both 0 and 1 at the same time—superposition. Ternary computer systems with the extra state have an exponential effect on computing capacity, which can further enhance computing, but in order for them to be useful to programmers, the organization of states needs to be codified in such a way that they can be employed. To compare the Ternary (sometimes called Trinary) numbers with Binary numbers in a four-bit register, click the Play button, and the Download button to download the code.

Currently, the “tree” of computing is the binary numbering system using the base 16 hexadecimal as the following set of numbers illustrates what can be placed in a 4-bit unit of computing space.

01-0000-0
02-0001-1
03-0010-2
04-0011-3
05-0100-4
06-0101-5
07-0110-6
08-0111-7
09-1000-8
10-1001-9
11-1010-A
12-1011-B
13-1100-C
14-1101-D
15-1110-E
16-1111 –F

Using 8-bit bytes, 256 different combinations (00 to FF) are possible. (Obviously, the more bytes used, the more combinations.) In a simple 8-bit computing environment, such as the 6502 processor (used in the early Apple computers), the next step up from the bit combination of 1s and 0s, was machine language that substituted hexadecimal values for operations. For example the following machine code stores the contents of the accumulator into an absolute address 7A4B.

    8D 4B 7A

The 8D value is more easily understood as the opcode, STA, which stands for “Store the contents of the accumulator in an address.” So now, you have,

    STA $7A4B

Suppose the contents of the accumulator create the string—“Hello.” The string is then stored in the address 7A4B. Just to make it simpler, suppose that we give a name to the address 7A4B and call it “Greeting.” So now we can say,

    Store the string “Hello” in the address named “Greeting.”

Another way we could state it would be,

    Greeting=”Hello”;

The engineering and programming behind the process is far more complex than explained here, but what we’re looking at is programming being built from one level of abstraction to another. (If you haven’t read the Pulitzer Prize winning book, The Soul of a New Machine by Tracy Kidder, you’re in for a real treat on creating a new miniprocessor chip (before microprocessor chips, they had the miniprocessor chips). After the project was over, one of the developers moved to Vermont where he wanted to

…deal with no unit of time shorter than a season.

Move Up to OOP

Having done a project where I microcoded a 4-bit robot microprocessor to interface with an 8-bit computer, I can tell you that coding in 0s and 1s is tedious. The machine language using a base-16 numbering system, while a lot better, was nowhere near as easy as using an assembler—really “high level” abstraction using opcodes. Of course, a higher level assembly language like Forth was even better, but involved far more coding than languages like C++ and certainly BASIC. ActionScript 3.0 seems to be about the same level of abstraction as Java and is empowered to work with more abstract concepts like classes and namespaces.

Having started on the binary level, which is one abstraction up from logic gates and electrical impulses, we’ve come to ActionScript 3.0 where we can use a single statement like,

    String.split(/~/);

to parse a giant string and turn the chunks into array elements. Granted you have to know a thing or two about Regular Expressions and the right method to employ along with the class that the method is associated with. However, it’s a lot easier than even thinking about doing that in a lower level language such as assembly language. Furthermore, by understanding ActionScript 3.0 (or any other language), the more you know about it, the more you can use the built-in operations to code even less.

When we talk of classes we’ve really talking about objects. As an object, we can make the class do a lot of things for us, but in order to use it we need to understand its properties and methods and any associated events. To some extent, there’s a tradeoff between the amount of time we need to study or use a class or a namespace and how useful it becomes. However, the fact that we can work with classes and their properties, methods and events, is a big clue that the language has moved to a higher level of abstraction.

Principles Are The Highest Level Of Abstraction

Keeping in mind that one level of abstraction is nothing more than an abstraction we can think of any level as abstract or concrete as any other. Thus, what are the trees and what are the forests changes with the level of abstraction. To be successful in programming is to be able to relate to different levels of programming abstractions. For the most part, we’d think that if we stuck with the IDE we’d be on a pretty firm base. That’s true until the IDE takes a drastic turn. The utility of the old Normal Mode in the Flash IDE drastically changed when ActionScript files were introduced. Likewise, with the advent of Flex, the IDE changed yet again from Flash to Flex for many developers.

Further, I don’t think that any developer who sticks with a single language is going to be too successful overall. Most ActionScript 3.0 developers I know are functionally knowledgeable in at least one middleware language like PHP, ASP.NET (C# or VB), ColdFusion or even Perl. Likewise, a lot of ActionScript developers work with Flash Media Server, and more and more are coming to ActionScript 3.0 via Java and C++.

By the same token that wrapping oneself in a single language is not a good career plan, I don’t think that holding on to a single design pattern is going to serve one too well either. I admit that I tend to do most of my work with the State, Strategy or Factory Method patterns, but as I begin to run into different kind of programming challenges, I start seriously reviewing the whole list of patterns. Further as Ian Cooper of CodeBetter.com points out, marrying a single framework isn’t such a hot idea either. While some frameworks, such as MVC, seem to be more stable than others, they too change and mature as witnessed in PureMCV. However, as Cooper notes, companies like Microsoft seem to have weekly frameworks and trying to keep up with them can be an exercise in futility not to mention taking time from better uses of your programming time.

Cooper suggests that the key to being a good programmer for any company, regardless of the framework du jour, is a solid understanding of OOP principles. Whether you should spend your time learning more about Cairngorm or Mate is pertinent insofar as a specific company is concerned (you’re up for a job interview and one of the requirements is knowing Cairngorm or Mate); however, overall, it’s less important than knowing the principles on which both are based—good OOP. Assuming you have a good handle on your development IDE and its toolkit, picking up a framework is certainly important, and a good foundation framework is MVC and derivations like PureMVC. However, where you see familiarity with Xframework in a job description, if you have a good sense of what the general principles are, you can familiarize yourself with a framework without having to memorize it.

Sliding Up and Down the Abstraction Pole: The Music Scan

During my preparation for an instrument rating in flying, one of the techniques we learned was the music scan. In instrument conditions (i.e., weather conditions that prevent visibility), pilots have to rely on their flight instruments. One of the dangers that pilots encounter while flying by Instrument Flight Rules (IFR) is fixating on a single instrument. For example, if you focus on your air speed indicator, you may be heading straight into the ground if you don’t check your altimeter, climb indicator and artificial horizon. To help pilots scan all of their instruments, they taught us to think of scanning the instruments as conducting an orchestra, humming ah-1 and ah-2 and scan all of the relevant instruments in an inverted “V” pattern. This may sound silly, but if you’ve ever encountered turbulence on a commercial flight, your attention can easily be fixated like a deer caught in headlights (AKA, “scared stupid”). For pilots of small planes that turbulence is multiplied several times and they’ll often fixate on one instrument while being shaken wildly. (Think of a coffee can containing a single marble being rattled by a crazed giant.)

In programming, we can be in danger of doing the same thing—fixating on a single level of abstraction. Rarely do we have to dip down to the level of assembly programming or even think about the binary logic that underlies our programs. The very best programmers I know will look at a problem from several different perspectives and on different levels of abstraction. OOP Principles are relevant to all layers of abstraction, but in particular from the level of operations on up to frameworks. In many ways, good programmers seem to live in a principle sandwich—principles surround them on all levels of programming.

• OOP Principles
• Frameworks
• Design Patterns
• Operations
• OOP Principles

For me, the biggest trap is getting stuck in an operational level—especially when I’m in a hurry. True, I’ll think of some principles (like encapsulate everything I can), but all too often I’ll crank out what amount to operational objects. However, if I go to the next level of abstraction, Design Patterns, all too often I’ll start with a Strategy pattern because its variation is an algorithm—too big of a temptation for an algorithm junkie. I suppose that’s an improvement since everything used to be State patterns. Likewise, I’m employing more Factory Method patterns, and so while I’m unstuck on a single pattern, I’ve still got to keep a music scan going—scanning design patterns in addition to levels of abstraction.

My next big leap is to a Framework. True, by combining design patterns, I’ve created little frameworks but I want to start with a nice simple MVC that can go into the Lunch Bucket series—a simple framework that can be taken to work. (Readers might also think about taking some of the PureMVC designs done by Chandima to work as well.) However, for the most part I’ll be sliding between the operational and design pattern levels. It’s not that frameworks of too abstract, but often they’re a bit too purpose oriented, and I like the granularity of design patterns. However, if I can find the right framework for the kinds of things that I typically do, I’ll adopt it—or develop a framework of my own.

Keep on Humming

As long as you force yourself to think about different levels of abstraction—a music scan of programming levels—you’ll be able to escape fixation on a single level. Abstractions are as concrete or abstract as you make them because ultimately they constitute perceptions. The OOP Principles seem to work pretty well from an operational level to a framework level, and that pretty much describes what we actually do in programming. Back in the day when I spent about 10 years with engineers from General Dynamics at weekly Forth meetings, I’m reminded of their insistence that C++ was a sham because it really wasn’t reusable code as promised. It worked differently with different processors, and only a language on the level of Forth could be trusted to do the right thing because with Forth you could program right down to the metal. They felt that if you could not take advantage of the different characteristics of the different CPUs you weren’t allowing yourself the full range of possibilities of your computer.

Unfortunately (or fortunately) very few programmers ever warmed up to Forth because of its reverse Polish notation (or Postfix notation) and low-level abstraction—as noted, it was really a higher-level assembly language. I learned a lot from Forth, and some of my own programming idiosyncrasies reflect that. However, I’m far more productive and comfortable in the higher-level languages such as ActionScript 3.0. Likewise, higher-level concepts such as OOP are vital to reusable and team-built projects. When OOP concepts can be cast in design patterns, it not only provides a common language on another level of abstraction, it increases re-usability and change of the program. Frameworks, organize operations and class relations on a still higher level of abstraction.

However, getting stuck on one level of abstraction, especially on an operational level where you’re trying to get the next algorithm to work is definitely a rut. Moving up to design patterns and OOP is a small but critical step, and it becomes as concrete as the operational level once you have practiced for a while. The trick is, though, to keep moving through the levels using OOP principles as the grease on the pole that allows you to slide to different levels and adapt to different levels. So if you ever find yourself in an abstraction rut on some level, just remember, ah-1 and ah-2.

The ActionScript 3.0 Design Patterns/OOP/Principles and Algorithms: The Forest and Trees of Programming by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. Index: ActionScript 3.0 Design Patterns Principles and Design Patterns at Work
2. OOP & Designs Pattern Principles: Ready for Work
3. No Time for OOP and Design Patterns