ActionScript 3.0 Design Patterns

In digging around for information on parallel programming I came across an Adobe post by Kevin Goldsmith from last September (2010). In the post Kevin encourages “academics” to heed the advice from Intel’s legions to “go parallel” citing the same article by Paul Steinberg I did in the previous post. This kind of post is most encouraging for those who are interested in parallel programming. What is maddenly frustrating about Kevin’s article is that while lots of tools are available from Microsoft’s .NET framework, we don’t see anything like the tools or language structures or libraries or anything else that would allow ActionScript 3.0 developers to heed the advice that Kevin so freely gives. He acts as though Flash Builder can even do some simple multithreading.

Particularly galling was Kevin’s pontification exhorting “academics” to get cracking with parallel programming (citing Paul Steinberg) :

If academia treats parallel programming and data structures like a specialized field of study, walled off into a couple courses and ignored by the general curricula, it will be doing a disservice to its students.

First of all universities do teach parallel programming. A new colleague of mine who just received his computer science Ph.D. from Georgia Tech (a southern version of MIT or India’s IIT) knew all about parallel programming; so, it is something that already is taught in “academia.” (That’s where the concepts were invented.)

Second, if we heeded Kevin’s advice, we’d drop the fledgling ActionScript 3.0 courses you can find here and there in universities and go C# big time. That’s because C# (along with Visual Studio 2010) support parallel programming and other than “my own team’s Pixel Bender in Flash” that Kevin mentions, there’s very little support for parallel programming from Adobe—at least support that’s visible and usable like it is with C# and the .NET framework.

Third, while there’s a brisk discussion at OOPSLA (SPLASH) meetings of parallel programming, there’s no one from Adobe there. (I’ve given several presentations using ActionScript 3.0 in design patterns at these meetings but have never met anyone from Adobe—lots from Microsoft though.) So, while MAX is dandy for the Adobe fanboys, and Intel Developers Forums are great for rallying Intel multicore solutions for hardware, the software giants are at OOPSLA where design patterns were invented. You’ll find (like me) that if you’re the dumbest person at a conference, you can learn a lot.

Let me apologize for this mid-week rant, but like a lot of us who are huge supporters of ActionScript 3.0, it’s very frustrating to see languages like C# and Java (and even Python) support parallel programming and then read a post like Kevin’s telling us to “hop to it” while not having the developer tools to do so. Even worse, if we took Kevin’s advice seriously, we’d probably use C# and C++ on the .NET framework and kiss ActionScript 3.0 goodbye.

Chimneys Allow Access

The other day I was working on some getters and setters to capture and encapsulate data passed from an input source. I’m most cognizant of using getters and setters for incoming data so that I have these nice encapsulated chunks of coded properties. The reason behind encapsulation is to keep properties from getting changed by other elements in a program unwittingly. So getters and setters became a recommended way of going about setting up data. (The terms mutators (setters) and accessors (getters) are often used to describe the same thing, but I can’t think of mutators without images of zombies, so I just use getters and setters like everyone else—conformist that I am.)

To be honest, most of the programs that I write using design patterns don’t have getters and setters per se, and I rarely use the ActionScript 3.0 get and set methods. Typically, a well-designed program has no need for explicit getters and setters. Nevertheless, on page 20 of our book, Chandima and I dutifully write about getters and setters as being a mundane aspect of OOP and provide several examples. However, over the years, I’ve seen a growing number of articles about the dark side of getters and setters. The issue is around what getters and setters were meant to do and how they have been misused.

If you think of a house as an object, and the doors as public access, both the opportunities and problems with object access become more apparent. Also, you have places where entry is possible but not intended—such as down the chimney. Anyway, I was moved to pen a season-appropriate missive to shed some light on the issue:

The Night Before OOP-SLA

‘Twas the night before OOPSLA, when all through the watt
Not a coder was stirring, not even a bot;
The downloads were placed on the server with care,
In hopes that St. Singleton soon would be there;
The young geeks were nestled all snug by their screens,
While visions of killer apps arose from their dreams;
And mamma with her iMac, and I with my Dell,
Had just settled down to write code for a spell,
When out on the net there arose such a clatter,
I sprang from my chair to see what was the matter.
Away to the keyboard I cranked up my Flash,
Tore open the folders and emptied the trash.
The apps on the iPod all came alive
Gave the lustre of update to objects on-drive,
When, what on my screen came clear in my glasses,
But a miniature program, and eight tiny classes,
With a little old hacker, so fat like a pork,
I knew in a moment it must be St. Dork.
More rapid than skip lists his coursers they came,
And he whistled, and shouted, and called them by name;
“Now, Factory! now, Context! now, Product and State!
On, Flyweight! on Proxy! on, Builder, Template!
To the top of the dock! to the top of the sprawl!
Now refractor! refractor! refractor all!”
As bits wrapped in packets over the routers do fly
When they meet with an obstacle they return to retry,
So up to the server the coursers they flew,
With program dependencies, errors, and St. Singleton too.
And then, in a twinkling, I picked up my mug
Full of java to seek out each little bug.
As I drew in my mouse, and was clicking around,
Down the accessor St. Singleton came with a bound.
He was messing with properties and methods to boot,
My encapsued objects were wrecked to the root;
A bundle of types he had flung on his back,
And he looked like a newbie overloading the stack.
His eyes — how they glazed! his pimples how icky!
His cheeks were like pizzas, his nose was still sticky!
His droll little mouth had precious few graces,
And when he smiled I was blinded by braces;
The stump of a pencil shown up from his pocket protector,
He stumbled around like Clouseau the inspector;
He had a broad face and was fat as a pie,
When he walked he looked like the Comic Book Guy.
He was chubby and plump, a right jolly old geek,
And I laughed when he tried to give my pattern a tweak;
A wink of his eye and a blast of hot gas,
Soon gave me to know that this guy was crass
He spoke not a word, but started hacking his work,
And filled all the memory; then turned like a jerk,
And laying his finger straight up his nose,
And giving a burp, up the access he rose;
He sprang to his program, to his team issued a command,
And the whole thing crashed like a wave on the sand,
But I heard him exclaim, ere he limped out of sight,

“Happy Coding to all and to all a good night.”

Happy Holidays from Bill and Chandima…

I just got back from the SPLASH (OOPSLA) conference in Reno. To be honest, I wasn’t looking forward to it because I had to present a paper to the Educational Symposium, and just about everybody there had a Ph.D. in computer science and I was going to be eaten alive. Besides, the usual group I do things with (Killer Examples) had decided not to hold their usual session and I didn’t know anyone in the Educational Symposium. To give you an idea of the session I was in; here are some topics:

• The impending ordinariness of teaching concurrent programming
• Mutation Analysis vs. Code Coverage in Automated Assessment of Students’ Testing Skills
• Compiler Construction With a Dash of Concurrency and an Embedded Twist
• Learning OOP with Dynamic Languages: Adding Concrete Strategies to a PHP Strategy Design Pattern
• Manifesto: a New Educational Programming Language

When someone is talking about the “ordinariness” of “concurrent programming” and I had no idea what concurrent programming was, I was a little rattled. However, everything was so interesting that I soon forgot about my own concerns and really got into these other topics. The big deal that hit me between the eyes was concurrent and parallel programming. (One undergraduate student had a presentation on CUDA, which is used in learning concurrent programming—it took him three hours to crank out “Hello World!”) When my turn came, it worked out well, and I survived and even had a good time. The presentation after mine was by three guys who were discussing the process of developing a new language called Grace. SPLASH has a humbling effect. (Click the link below and learn how I met one of the Gang of Four.)
Read more…

The other day I was worrying about a comment another programmer had made. After looking at some code, he twisted up his face and said,

“That’s not the way I’d do it.”

He went on to tell me how he’d do it. After thinking about it a couple of days I realized that the way he’d do it, while not wrong, wasn’t any better than what was originally there. In grousing about it, the chairman of the Computer Science Department remarked,

Yeah, that’s just like a programmer.

While that made me feel better, it was also aggravating. Out of sheer habit, what compels programmers to be so petty? I don’t mind a little one-upmanship, but some discussions need to be about finding a better solution and not forever trying to tell someone how smart you are. (By the way, this isn’t the first time I’ve mentioned this problem in a post, but I’d like this to be an invitational rant and get some reader comments.)

I’ve worked with people in a lot of different fields, and while some pettiness can be found in just about all professions, We’re Number One! when it comes to the That’s not the way I’d do it (TNTWIDI—pronounced tin-widi with a short “i”) syndrome.
Read more…

Tomorrow morning bright and early I’m off to Orlando, Florida for the 2009 Object Oriented Programming and System Languages Association (OOPSLA) annual meetings. I’ll be making an ActionScript 3.0 presentation in a workshop on Sunday. Our workshop is named “Good Examples for Exposing Bad Practice” and meets in Pastoral 3 from 8:30-5:00 (Oct 25) Mine is based on the ‘Wrong Way Warrior”; so it should be familiar. On Monday, I’ll be at the Educators Symposium all day, and I would really like to meet other ActionScripters who might be at the conference

Here are some other speakers you might want to hear/meet:
1. Miško Hevery
Automatic Dependency Injection In The Land Of Dynamic Languages

2. Barbara Liskov (Liskov Principle)
Keynote Speaker

3. Ralph Johnson (GoF)
Regrowing a Language: Refactoring Tools Allow Programming Languages to Evolve

Anyway, just in case any of you will be there, drop by one of the sessions. Everyone’s been very accepting of ActionScript 3.0, and it’d be fun to chat with some fellow ActionScripters!

Some years back when I was flying with Flying Samaritans, I was invited to a party for a fellow pilot in Beverly Hills, California. Since the party involved a good deal of celebration, I had to stay over—no way I was going to fly back to San Diego that evening. The house we stayed in was a classic early California-Spanish design; a beauty in every way. The next morning, bright and early, I went for a walk along well-tended streets where no pothole or crack in the pavement dared to show itself. The streets were immaculate, as were the sidewalks and everything between the houses along and off Beverly Drive.
Read more…

In a recent post I voiced my admiration for artists, designers and animators but noted that they seem to have been left out in the cold with ActionScript 3.0. I added a little helper statement not in the ActionScript 3.0 documentation—MovieClip.addFrameScript(). The idea was to encourage artists not to be too hasty in giving up on coding altogether.

Quite frankly, I was surprised by the number of comments we received on that post. I didn’t think artists bothered with our kind of discussions, and was more than a little gratified to find that some of our readers identified with the issues discussed. So I started thinking about a series of posts for helping artists.

I didn’t want to do a “dumbed down” ActionScript 3.0 for artists; so I opted for an approach that would cover the same principles that we’ve discussed throughout the life of this blog. However, I would move more deliberately and touch more bases—especially the basics of OOP. Further, I decided to use video and take advantage of the new Quicktime Player that comes with Screen Sharing. So, I created a simple class to start things off, and put it in an .f4v file (H.264 format) and you can download it by clicking the download button:

You will need an Adobe Media Player that is free to download. I did not include any .fla files because I’d have to put in at least two because some have CS3 and others CS4; so you’ll have to use your own .fla files. Each video is short and will play full screen using the Adobe Media Player. The only thing I need is feedback to let me know whether this kind of thing is helpful or not. I will be focusing on graphics and loading graphics, but I welcome ideas from one and all.

Artists and Graphic Designers

For me, graphic designers and artists are angels. No matter how I try, I can only get so far in graphic design. Tools like clip art, templates, and Kuler help me achieve not awful , but that’s it. (I can even screw up clip art.) So, for anything serious, I’ve got to work with graphic artists. That’s no problem—I like working with angels.

Some graphic artist have made the transition to some version of ActionScript, but with ActionScript 3.0 most complained that they were getting left behind. Early Flash had few ActionScript options and a system for entering code that didn’t require any programming background at all. With ActionScript 2.0, things got better for developers, but designers started voicing concern over increased complexity. With ActionScript 3.0 and the loss of the ability to put code into buttons and MovieClip objects directly, some graphic artists became furious with Flash over what they saw as a betrayal. It was like a carload of kids on the way to do something fun ditched the artists and designers on the roadside.
Read more…

In the little AIR menu with the 10 principles one of the clearest is the Open/Closed Principle. At one time this principle suggested that all updates be created using an implementation or extension of virtually any class. That could get tricky, especially if someone understood that to mean implementing an update or extending a subclass. However, later, the extension came to mean the extension of an abstract base class. In other words the interface is extended but never modified. Given these caveats, we can understand the basic principle as it is now understood:

Classes should be open for extension but closed for modification.

Easy to Take to Work

(Note: In talking about a program and changes, we’re not including the Client class. It just makes requests, and you can add requests and change them all you want in the Client.)

The idea that when you want to change a program, the only way you are able to make changes is by extension may seem a little restrictive. However, what the principle is really doing is providing a way to make changes without having to rewrite the whole program. The dictum, New behaviors are only available through extension should not be phrased in a way to make it sound like it’s tying your hands. Rather, it should say something like,

Hey! The Open/Closed principle makes it easy to add new behaviors without having to mess up your whole program.

Read more…

Gentle Reader: Now that we’ve worked through all of the design patterns in ActionScript 3.0 from GoF (well, Builder is still in the works, but that’ll be available soon), now would be a good time start going through the principles underlying design patterns. This will be the first in that series.

The 1987 OOPSLA keynote address by Barbara Liskov contained what has become known as the Liskov Substitution Principle (LSP). Essentially, the principle holds that

If a Client is using a reference to a base class it should be able to substitute a derived class for it without affecting the program’s operation 

(Actually Dr. Liskov said something more like:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

but I’m not about to…)

If the Client has an object of a certain type, it should be able to substitute a derived object of the same type. For example, suppose you have an abstract class named Automobile and from that class you have subclasses of Ford, Toyota, and Peugeot. Your Client has an object, myAuto:Automobile. The myAuto object can be any of the subclasses, and if a substitution is made for any one of them everything keeps on working without a problem and the change is unknown to the Client. So if you substitute a Ford for a Toyota, the Client can work with the objects without having to adjust for the change. What’s more, if you want to add a Fiat class as a subclass of Automobile, the myAuto object handles it with nary a whimper.

The one caveat is that the subclasses must all honor the contractual conditions of the parent class. So, any methods in the parent class must be functioning in the subclass (aka, derived class.)

Now you may be thinking, So what? If you’re at all familiar with other principles of OOP and Design Patterns, this principle may sound vaguely familiar, but what is the importance of this concept/principle/idea? It is this: Because the Client is unaware of the concrete class that the object may implement, the structure is far more resilient. Not only can the same structure be reused, it can be changed, updated and generally fiddled with without easily breaking anything. (Think of adding more car manufacturers to the Automobile class.) As far as the Client is concerned, as long as the interface rules are followed with the object, everything is hunky-dory.
Read more…