Take a Design Pattern to Work Part I: Identifying the Problem

New Year’s Resolution

Happy New Year! Now’s the time to resolve to be better in many ways, and one compartment of improvement for me is in programming. In this time of multitasking, I find that I can do a lot better if I focus on one thing at a time, and so compartmentalization really helps—sort of like encapsulation. Further, I find it helpful to have a plan on how to go about whatever change I want to make; so this year my plan is step-by-step to improve my programming habits. However, the first step is to identify the problem and deal with the realities in the problem.

Lions Led by Asses

During World War II in North Africa, one German commander described the British army as lions led by asses. Now I’m not one to claim that developers should take over management and lead us all to a new day and brighter world. However, on occasion I’ve run into situations where someone makes seriously stupid demands that can waste time and possibly destroy a project. Let me share the kind of real-world situation I’m talking about.

During one project, I created an example of bringing in content from external text files using ActionScript 3.0. The example was to show how to create dynamic text in a simple text file so that customers could change text files and maintain the content of their own Web site. For the content I provided an example of travel to very poor countries by a clueless vacationer. One of the people responsible for reviewing the program examples threw a tizzy fit and claimed I was mocking poor countries and demanded that I re-do the entire program. (Actually I was mocking the lack of awareness of poverty, but the reviewer didn’t get that either.) As anyone reading this blog realizes, all I had to do was to change the content of the example text file, and that would solve the problem of what was viewed as political incorrectness.

A long time ago I learned to pick my battles carefully. So rather than going into a detailed explanation of what I was attempting to do and taking a stand against what I saw as monumental ignorance, I simply changed the content of the text file (which was the whole point of the example in the first place). That took all of 10 minutes. The reviewer had every right to tell me to change the content of the example, but she was way out of her depth in telling me to re-write the whole example. That would have been a waste of time and messed up a useful example. She was totally unaware of what the example was all about—the content was immaterial. It was all about flexibility in using ActionScript 3.0 and allowing customers to make changes on their own. Much later in the project, I got a follow-up email from a manager checking to make sure the example was changed. I assured her it was and sent her the revised text files as proof. There was no big fight, angst, and, most importantly, wasted time and effort. We all have only so much psychic energy. It’s the kind of energy we use for working out algorithms, design patterns and other cognitive chores. You’ve only got so much before your brain says, “Enough! I’m pooped!” Don’t waste it on unnecessary fights or gnashing your teeth over bad decisions or unfortunate management choices.

They’re going to eat our lunch or Keeping up with the Jones

As a matter of course, I avoid bumper sticker mentality, especially those dreamed up by marketing and management types. However, some are useful. One that sounds crude but is a nice clear declarative statement is:

They’re going to eat our lunch!

In the world of competitive business that pretty much sums up what happens if you lose the contract to the other company. That statement is important because it resonates with management. Suppose you attend a MAX or OOPSLA conference and come back with your hair on fire to introduce a great OOP or Design Pattern concept. If you run into your boss’ office and start talking in DP-babble, you’re likely to get a 1000-yard stare and perhaps a chuckle that you’re all excited about something that is work-related. However, nothing is likely to change.

On the other hand, if you point out that the competition is likely to eat our lunch if you fail to change your programming practices, you’re more likely to get the kind of response you’re looking for. Further, if you have a practical answer to the question of getting the job done in a more effective and efficient manner, you’re even more likely to get a positive result. Unfortunately, some bosses are hopeless, as I am daily reminded by my Dilbert calendar. In that case, save your psychic energy for updating your resume or getting your own business off the ground. However, for a moderately decent manager, they are more likely to listen to someone who speaks their language and provides a solution to a problem.

How to Fail

One of the most debilitating bumper sticker mindsets is summed up in the hopelessly insipid slogan,

If it ain’t broke, don’t fix it!

In technology, that slogan has the same effect as,

Put gun to head and pull trigger!

Imagine if we were still using the ActionScript that was provided with Flash 3. We would be unable to do much more than use Flash to make animated banners and maybe use a few gotoAndStop() ActionScript statements. Flash 3 worked just fine for what it was designed to do. So why fix it? It wasn’t broke. It was improved and continues to be both as new versions of Flash and Flex are introduced.

This is not to say to institute change for the sake of change. Rather, unquestioned adherence to a set of antiquated processes that function is a dangerous and bad habit. It’s dangerous because the competition can adopt more efficient and effective procedures and produce better, quicker, and cheaper software. Good practices are not good because of some Puritanical ethic. Rather, they’re good because they function better. So if you’re in the habit of doing things the way you always have because that’s what you are expected to do at work, you’ve got a bad habit. This is not the time to find religion and pray for a rational world, but rather use the available programming tools and adopt some good habits with those tools. This is where Design Patterns come in.

Take a Design Pattern to Work

Not too long ago on this blog we had a post, No Time for OOP and Design Patterns and many readers responded with valuable comments about working in the real world of getting projects out the door. Rather than grumbling (or worse, whine) about the press of work and the inability to sit down and really architect a project, I’d like to start a dialog for introducing design patterns to the work place. The goal is to bring in all of the advantages of good OOP and design patterns into the workplace and use them effectively, profitably and on time. Even better, the goal should be to re-use them. Then your projects are sitting on top of good solid bedrock and not the sandy foundation of weak coding practices. Good design patterns make code easier to change, update and have less chance of a glitch that will ruin your day.

In order to get this done, you cannot introduce design patterns into a group of novice programmers, especially if they have no OOP background or a desire to become better programmers. So showing up to work with good intentions and a book on design patterns will do nothing more than to generate grumbles of “not now.” Instead, you need two useful strategies.

First, I think that any ActionScript 3.0 developer needs an OOP mindset with at least a couple of design patterns (not including Singletons) that she can use easily. If you cannot intuitively think of solving problems in terms of encapsulation, inheritance and other OOP concepts, it may be very difficult to clearly communicate to others why they should consider OOP. Likewise, the more general design patterns like the Strategy, Factory Method, Composite, and Observer are good to know because of their more general application. Knowing about MVC is equally important. (It tends to come up in a lot of design pattern discussions.) The main skill to develop and share is the ability to look at problems and come up with sensible solutions using a design pattern. Think of this as mental preparation.

Second, find a recurrent problem (task) that can be handled well by a design pattern and just show up with it. When I first started working with the State design, I found it to be a perfect solution for dealing with a Flash video player. Since I first developed it, I’ve used the State pattern video player in several different configurations over and over. Like all good design patterns the classes are loosely coupled and so making changes in one class can be handled as a separate state without disrupting the rest of the program. It’s practical and I’ve worked with it enough to really understand its nuances. If asked, I can explain it to just about anyone in terms of both a state machine and a State design pattern. So if you bring in a design pattern be sure that you can deftly work with it and easily explain it to others.

A Simple Start

For the last month or so I’ve been working on a presentation I’m going to make to the Atlanta Flash Flex User Group. Using the ideas developed for the Atlanta group, I’d like to trace a traditional Flash solution from old school ActionScript through an OOP solution, to a partial design pattern to a full design pattern. This first step will be a simple ActionScript solution wrapped up in Flash. Before going on to the next step, an OOP solution, I’d like to get feedback from this group to how you think a simple OOP solution to the problem should look. You’ll be provided with the full starting point with a Flash MX 2004 application. We’ll move from Flash MX 2004 to ActionScript 3.0 in either Flash or Flex.

The initial design is set up to display graphics and text that display the different staff members of a Web development shop. The playhead on the Timeline is moved by simple ActionScript using anonymous functions. The following script is associated with the first keyframe on an ActionScript layer.

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

stop();
logo.onRelease = function() {
	gotoAndStop(1);
};
aBtn.onRelease = function() {
	gotoAndStop(2);
};
bBtn.onRelease = function() {
	gotoAndStop(3);
};
cBtn.onRelease = function() {
	gotoAndStop(4);
};

We could have taken it a step further back in time by associating the ActionScript with each button and the movie clip (logo), but that is not necessary for the purposes of the illustration. (I suppose you can find a few Web design/development agencies that still embed their code in movie clips and buttons. Shudder!) Figure 1 shows the related Flash page. Each keyframe in the Options layer has a different image and static text name.

Figure 1: Simple ActionScript and Timeline solution

For the purposes of eventually bringing a design pattern to work, this has been kept simple. However, it is functional, and it is relatively simple to update. As new personnel join the staff, new keyframes can be inserted and buttons added along with another anonymous ActionScript function. You can get a better idea of how it works here. If you want to open it in Flash, you can get the compressed file here.

In looking at this, the mantra of If it ain’t broke, don’t fix it comes to mind. So, assuming that the staff in this company is going to grow quickly, identify the problems inherent in the design that suggest that not only is it broke but you have ways of fixing it with better program design.

Encapsulate that What Varies

As a starting point, the Gang of Four suggests that you consider what you want to vary in the program and encapsulate it. (See page 29 in GoF or page 337 in our book.) This approach is the opposite of the focus on redesign. Instead focus on what you want to change without having to redesign the whole program.

In Part 2 of Take a Design Pattern to Work we’ll look an OOP solution to get started. In the meantime, we’re always interested in your ideas and comments.

The Take a Design Pattern to Work Part I: Identifying the Problem by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.