ActionScript 3.0 Design Patterns

In looking for details about the Dependency Inversion Principle, I came across an article by Robert C. Martin in which he discusses a situation where one software developer looks at another’s application. Because I’ve had similar experiences, along with the exasperation developers feel for such comments, I thought I’d include it here—paraphrased as it were. He beautifully portrays the adolescent sniveling where the other’s comment is all too often,

That’s not the way I would have done it…

In several states I believe such comments are grounds for justifiable homicide. Not only is that kind of comment indicative of a certain type of nastiness, it is generally not helpful. Being as immature as the next guy, my general response is usually something like,

Okay smarty, how would you have done it?

This kind of brain-dead twittering misses the crucial point of what is good software design? Maybe I did indeed do it all wrong, but by what criteria do we judge good design? To some extend the answer lies in all of the discussion about OOP and Design Pattern principles we’ve covered on this blog and in our book. Martin provides a nice set of good design indicators that encapsulate much of our discussions.

The Three Keys of Good Design

Martin starts off by noting three key flaws that are red flags for poor design, and then he flips them to show the good design features. I’ll do the opposite—start with the positive and then move to the dark side:

1. Flexible. It is easy to change because changing one part does not affect every other part.
2. Robust. When you make a change parts of your program do not break.
3. Reusable. You have no problems taking parts or big hunks of code and reusing it in other programs.

Okay, that’s it. You are now armed with the sine qua non of design patterns (better known as the whole enchilada of why we bother with design patterns and OOP principles.)

The Dark Side: Signs of Bad Design

Usually when discussing good and bad design, we get more of the latter and less of the former. However, Martin has equal weight to both.

1. Rigid. When you change one thing, several other elements of the program change as well.
2. Fragile. You may break something simply by changing something else.
3. Immobile. Instead of being able to reuse the code, you have to start anew whenever you program anything.

Just looking at the dark side makes me squirm. Shudder.

Into the Lunch Bucket

Even though the design keys enumerated by Martin aren’t part of our list of 10 Principles, they’re a handy set of criteria that are easy to take to work. So the next time you hear, That’s not that way I’d do it you can reply,

What criteria do you use in the way you do it?

If they can’t provide the criteria, tell them about the three we’ve discussed here. The next time, before they tell you they’d do it differently, they’ll have to prepare for a quiz and then remember the criteria.

Related posts:

1. No New is Good New: Using Inheritance, Composition, Delegation and anything else other than New in ActionScript 3.0 Design Patterns