ActionScript 3.0 Design Patterns

A Closer Look

Gentle Reader Every now and then I run into something of possible interest to ActionScript 3.0 and Design Patterns. Since I spend a lot of time in the forest (Design Patterns), I may miss the trees (Program Elements). So what I may run across might be known (and obvious) to all but me. On the other hand, some may find these short digressions of possible interest and use. So as to alert readers to these random snippets I put together a Closer Look logo for these small posts that live in the nooks and crannies of OOP and Design Patterns.

Programming with MovieClips in the Library

When you create a MovieClip in the Library and set it up for Export to ActionScript, you can treat it as a child of the MovieClip class. Basically, a named MovieClip in the Library is the same as setting it up as:

        public class MyMC extends MovieClip …

One of the fundamental design pattern principles is program to an interface; not an implementation. For example, instead of declaring a movie clip instance as,

        private var myInstance: MyMC = new MyMC()

Read more…

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…

If you’ve put off entering one of the Golden Lunch Bucket Contests, you’ll not want to miss this one. This one is as easy as pie. In a recent post, Wrong Way Warrior Part II, the Warrior class was modified to get its weapon behaviors from another interface named Fire. The Warrior class did nothing more than extend the Sprite class and set up a reference to the Fire interface. However, you will notice that two other behaviors were implied in the commented-out references to Movement and Communicate as shown below:

1
2
3
4
5
6

       public class Warrior extends Sprite
	{
		protected var fire:Fire;
		//protected var movement:Movement;
		//protected var comm:Communicate;
	}

For this contest, all you have to do is to create the necessary interfaces and classes only for Movement (we’re saving the Communicate until later) so that the Warrior instances will retain their current weapons behavior but include the Movement behavior as well. The movement algorithms must come from a separate interface and concrete movement implementations (just like Fire did).
Read more…

In the third Golden Lunch Bucket Contest, Timo Hannelin again sent in the winning entry and added four more points to Finland’s lead in the Golden Lunch Bucket World Cup.

We’re hoping to expand the number of entries, and so the next contest will have the basic design pattern laid out, and the entries will simply have to extend it. That will be out next week.
Read more…

Tight Code and Tighter Programmers

The other day I was thinking about programs with tight code and loose coupling. Having been raised on tight coding I started looking around for a decent definition of tight code and came across one of my programming heroes, Charles H. Moore, inventor of FORTH programming language. For Moore, as well as others discussing tight code, the term refers to

… a program that is written very efficiently.

That doesn’t say a whole lot, but it says everything. In FORTH, not a single electron is wasted in the code, but not a lot of people use it because you have to think like a processing stack—last in first off. In other words, you have to think exactly backwards from normal sequencing. Ergo, most programmers have migrated to a high level languages with a C++ type of format such as ECMAScript and ActionScript 3.0. To some extent, efficient code is code without superfluous elements that gets a job done. (That’s why I don’t like to use conditional statements where I can help it—there’s generally a more direct option.)

In the context of OOP, I think that tight code can be equated with tightly woven objects. Such objects are good at what they do and nothing else. We can apply the single responsibility rule:

A class should only have a single responsibility.

However, they can work with other objects.
Read more…

Gentle Reader: This is the second part of a two-part set of posts. For this one to be useful, please take a look at Part I. Also, I’m not an expert on military operations or organizations; so if there’s any error in a basic infantry platoon, feel free to correct me. I am aware, however, of the 7-1 ratio of Service to Combat units in the modern military, and that this is only a simple component of a far more sophisticated structure—that’s why I selected it!

In the first installment of the Wrong Way Warrior, we saw how an OOP developer put together a simple proof-of-concept using what he thought was a prudent approach to a battle simulation. He’d provide the Warrior with certain characteristics and then subclass those characteristics to concrete warriors that would share the capabilities of the parent class. In addition, the concrete warriors would be given a movie clip representation of the warrior.

After the first design was sent to the customer, the response was less than favorable. It was described as “a children’s game” at best. The military advisor described it as a caveman battle plan where all of the combatants are similarly armed with a club to attack adversaries. The problem was that it was bound to a fairly static design, and it would be impossible to be used for a simulation that had more complex behaviors. However, the other submissions were not much better, and so the customer provided a simple organization within the military to simulate—the basic infantry platoon. After all, they’re paying your company $1.5 million to develop the simulation. (This was news to the developer!) Figure 1 shows the organization in terms of a new set of movie clips:

Figure 1: Movie clip representation of platoon
Read more…

In preparing for this year’s OOPSLA conference where my session will focus on demonstrating good practices by showing examples of poor practices, I was reminded of the first chapter of the Freemans’ wonderful book, Head First Design Patterns (O’Reilly). To introduce the reader to design patterns in Java, the Freemans set up an example where a developer got in trouble because his program could not be expanded or changed without taking the whole thing apart and putting it back together again. In their wisdom, the Freemans wanted to kick things off with practical reasons for using design patterns—not just because doing so is the right thing to do.

In some recent discussions, I’ve heard references to OOP and design patterns as a religion or mockingly called “doing it right” as though design patterns are some kind of moral imperative by obsessive-compulsive developers rather than practical solutions to programming problems. Any kind of programming solution should be a solution that does a good job of solving a problem and nothing more. Discussions of OOP and design patterns as the right way to get things done has no resonance with me at all; so I’m the wrong person to suggest that faith in design patterns is sufficient reason to use them.
Read more…