Archive for the 'OOP' Category

Page 3 of 9

Take a Design Pattern to Work Part II: A Little OOP

Published on January 5, 2009 in ActionScript, Design Patterns, Design Patterns at Work, Flash, Flex and OOP. by William B. Sanders 9 Comments

Gentle Readers: Before reading this post, you’re advised to look at Take a Design Pattern to Work Part I: Identifying the Problem. It provides the necessary context for this post. Also, keep in mind that this series of posts is walking through a process and some of the steps may seem way too simple. We’re trying to imagine communicating with others who may not be as technically adept as you, and each step is simplified.

Getting Off the Timeline

As the readers of this blog are well aware, the Timeline in Flash is a valuable tool for animation. By using the Timeline in conjunction with symbols, IK and tweening, all kinds of wonderful creations are possible. However, the Timeline is not a good place for code, and again, this is nothing new to readers of this blog. So why bring it up?

If you peruse the ActionScript job openings at places like Dice.com and Monster.com, you’ll find openings that include the following requirements:

The successful candidate should have at least three years experience using ActionScript 2.0 with knowledge of ActionScript 3.0 a plus. He/she should also have the ability to maintain and update legacy Flash sites with ActionScript 1.0. A knowledge of OO programming and design patterns is strongly desirable.

Work that includes maintaining a site written in ActionScript 1.0 (and even ActionScript 2.0 in some cases) almost certainly means that some or all of the code is written on the Timeline and possibly even embedded in the individual symbols —buttons and movie clips. In other words, a good deal of the work is playing Where’s Waldo? with the ActionScript scattered all over the place. For me, working to maintain such a site is somewhere south of Dante’s 9th Circle of Hell. (You remember Dante’s Divine Comedy from that humanities class you had to take.)

In Part I of this post series, the code is embedded in an ActionScript layer on the Timeline. Maintaining the site is pretty simple both in making changes and adding new materials. The developer makes changes by changing the image file and the text contents in any single keyframe. Additions are made by adding keyframes in the Options layer, code in the ActionScript layer and buttons in the Buttons layer. That’s not a difficult plan. So why change?

With a relatively small staff in the company, there’s probably no reason to change it at all. However, as the staff grows or they want to add more to the site, especially in terms of additional graphics and animated materials, the size of the SWF file grows as well. Pretty soon, you’re making pre-loaders, and that’s a good sign that you’re in trouble.

In addition to the problems in generating a big fat SWF file, a single set of ActionScript statements can only grow into a larger and less manageable set of code. For a small application, it works fine, but as applications grow, unless some of the inherent problems are addressed, an error prone application begins to emerge. Change becomes more problematic and the program begins to lose functionality as well as flexibility.

Continue reading ‘Take a Design Pattern to Work Part II: A Little OOP’

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

Published on January 1, 2009 in ActionScript, Design Patterns, Design Patterns at Work, Flash, Flex and OOP. by William B. Sanders 6 Comments

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.

Continue reading ‘Take a Design Pattern to Work Part I: Identifying the Problem’

Guest Post: Pieter Grobler- Understanding Design Patterns through Science Fiction

Published on December 24, 2008 in ActionScript, Design Patterns, Flash, Flex and OOP. by William B. Sanders 2 Comments

Gentle Readers: Chandima and I decided to try something new. Pieter Grobler wrote a science fiction story to bring out the key elements in the Chain of Responsibility design pattern. We hope that the story will be helpful in grasping some of the main concepts in the pattern. Most importantly, though, we need your feedback. Tell us what you think. Should we run more such stories or not? Chandima and I will continue doing what we do, but we are interested in other creative approaches such as Pieter’s. So use the comment box to give us your feedback.

Conquering Ratas (CoR)

The Hissians are a peaceful people. For generations, they have had to stand up against a great threat – not from the outside worlds, but a threat that are inherently part of themselves. In the face of danger, a Hissian has the ability to pass on the Message – a telepathic sort of communication, linked to only one other inhabitant. To the day, it remains an inexplicable passage of consciousness between all living creatures of the planet. Yet, calling on this power exerts great physical effort, and has proven to be fatal in the past.

Recently, there has been an ensuing series of threats from the neighbouring planet of Ratas, the home of ill-willed, brutal barbarians. For this reason, a soldier was sent out to Ratas to investigate the nature of the threats. He is brutally killed and sent back home, badly mutilated. Accompanying the gruelling package, is a warning message implying that Hissa would be harshly punished for their offensive curiosity.

So, Hissa prepares for the attack by way of setting up a defensive effort, which is planned and rehearsed to the letter, based on sensitive information supplied by Irgir, a Ratasian student under the great Hissian Philosopher, Riughadas. The plan rests on the idea to have Yarayara, the old lady of Pagh, pick berries in the area where the Ratasian forces plan to land. Her magical and seductive powers will then subliminally persuade them to try the Paghiby Berries – a rare cultivar with poison so strong, that it instantly boils the consumer’s blood, causing a biological malfunction, which creates such pressure in an organism, that its structure inevitably tears itself up, obliterating all surroundings in the violent process.

But this has been doomed to failure since the beginning, for its application was too specific, and the foreign soldiers were in no mood for tasting berries. Instead, they prompted Yarayara to prove the planet’s good intent by eating them herself. As she knew her fate, she ran her veinous hand down the scarf that her daughter – her only family – had given her. Brutal murder followed as homes in the peaceful village of Pagh were raided, their inhabitants pinned to the walls, left there as dripping trophees of Ratasian rage.

Then, on a beautiful morning, soaked in a reddish glow from the Star, it happened. Young Eileva, a selfish and spoilt girl was waddling away from her mother in teenage rage, when she saw the black masses of Ratasian soldiers approaching. She hesitated, only to be swept into a primal, instinctive urge to notify her predestined successor – her mother. And, as soon as the Message had reached her mother, Eileva bounced on the ground, her rotund little body progressively accelerating down the meadow.

Continue reading ‘Guest Post: Pieter Grobler- Understanding Design Patterns through Science Fiction’

ActionScript 3.0, Design Patterns and Polymorphism: What’s the Point?

Published on December 19, 2008 in ActionScript, Design Patterns, Flash, Flex, OOP and Polymorphism. by William B. Sanders 24 Comments

*Note to our gentle readers: This is one of those blog entries that probably raises more issues than it resolves. Further, it requests reader input. Consider yourself forewarned.

Why Polymorphism?

As just about everybody reading this blog knows, polymorphism is a foundational concept in object oriented programming (OOP). We devote several pages to polymorphism in our introductory chapter showing what it can do and what it looks like using several examples. (In fact I think we did a pretty decent job) However, I still don’t have the same kind of intuitive sense for polymorphism as I do for encapsulation, inheritance and some of the other concepts that make up OOP and more importantly, design patterns.

I went to my bookcase and found lots of discussion of polymorphism, and on the Web I found lots more. What’s missing (for me at least) is a visceral connection between polymorphism and design patterns. We can all talk about overloading methods, using interfaces to achieve polymorphism and provide all sorts of examples. But that’s not the same thing as smoothly working in polymorphism as a thought pattern when programming. I wondered if anyone else had the same minor intellectual itch that I do, and lo and behold in the Wikipedia entry on type polymorphism I found the following note:

All or part of this article may be confusing or unclear.

Such a notice is another way of saying it doesn’t make a lick of sense. This is not to say that the explanation is inaccurate. Technically, it’s very accurate as far as I could see. It’s just not very clear.

Continue reading ‘ActionScript 3.0, Design Patterns and Polymorphism: What’s the Point?’

ActionScript 3.0 Interpreter Design Pattern: A PostScript Tutor

Published on December 14, 2008 in ActionScript, Design Patterns, Flash, Flex, Interpreter and OOP. by William B. Sanders 2 Comments

ActionScript 3.0 Interpreter Design Pattern

Back in the day I used to do a lot of FORTH programming. For about 10 years I’d attend a weekly meeting of FORTH programming engineers at General Dynamics in San Diego and marvel at what they could do with this postfix language. (Postfix is often called reverse Polish notation after the Polish mathematician Jan Łukasiewicz who developed the mathematical notation placing the operator after the operands.) The following shows an example of this notation:

30 2 * 4 +
Result: 64

Later, when Adobe came out with PostScript and Apple came out with their first laser printer, I was able to program in PostScript using a text editor and shooting it directly to the printer. Out would come these fabulous fonts, drawings and whatever else I had programmed in. Because PostScript used a similar postfix notation as FORTH, I was allowed to do a FORTH newsletter in PostScript. Only a few were produced since it was no easy task to develop a newsletter in code using Notepad! (Click here to see the final PostScript calculator that this application generates. It works with PostScript data entry — use add, sub, mul, and div for +, -, *, and / respectively.)

Interpret This!

The Interpreter design pattern as described by Gamma, et al can be used to express instances of a recurring problem as sentences. Interpreting the sentences then solves the problem. Right off the bat I was thinking, ¿como está usted? translates to how’s it going? but that’s not exactly what GoF had in mind. Any spoken language is a bit too big for this kind of interpreter. Instead, the pattern describes how to define a grammar for simple languages. Gamma and his associates use the example of regular expressions, so loved by Perl programmers.

So when I went looking at some Interpreter examples, besides regular expressions, I found converters from Roman numerals to regular numbers, a Boolean language, a musical note interpreter from do, rey, me, fa, so, la, ti to Hertz (Hz) values, calculations using postfix notations and some other fairly modest examples. Because of my experiences with postfix languages, I decided to do one that set up as a PostScript data entry that would resolve to an outcome (solution) to the results of a postfix statement. I decided on PostScript whose math operators are word-like and not symbols. (e.g., Instead of using / for division, it uses div.) This would be a little more than the usual minimalist example since the user can use it to practice and learn PostScript math entries.

Interpreter Design Pattern Formal Features

Figure 1 provides an overview of the Interpreter pattern. Note that the Client is part of the pattern (instead of implied or not at all). Also note that the Client holds references to both the Context class and AbstractExpression interface.

Figure 1: Interpreter Class Diagram

Of all of the design patterns I’ve seen, this one has the most loose ends. Any statement put into a string and then interpreted generally requires some kind of parsing. GoF note the need for parsing and point out it can be from a table driven source, a recursive descent (or some other hand-crafted parser) or in the Client. The Context class is used as a global entry point for the Interpreter. It’s probably heresy to do so, but I decided to put the parser in the Context. The Client sends the request to the Context and indirectly to the AbstractExpression. The Context class still acts as a global entry point, but it also parses the data (statement in PostScript notation), and the Terminal Expression classes still do the actual interpretation. I don’t see it as adding tighter coupling. (If the parser were placed in the Client, I suppose it would be a purer version of the design pattern. If you think so, I’d like to see your implementation, and I’d be glad to put it on this blog.) Also, like most of the examples that I saw, this one does not include a NonterminalExpression. That is because I did not need alternation, repetition or sequence expressions.

The good news is that this implementation of the design pattern is wonderfully flexible and easy to update. If I wanted to change the language example from PostScript to something like Scheme, the pattern would be able to handle it with ease. Eventually, I’d like to re-do it with the parser in the Client and add several PostScript drawing commands by adding more terminal expression classes. I’d also like to add a NonterminalExpression for handling certain repetitions and sequences.
Continue reading ‘ActionScript 3.0 Interpreter Design Pattern: A PostScript Tutor’