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()
Continue reading ‘A Closer Look: Programming Library MovieClips to an Interface’
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.
Continue reading ‘Artists, Animators and ActionScript 3.0′
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).
Continue reading ‘Golden Lunch Bucket Contest #4: Extending the Warrior’
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.
Continue reading ‘Finland Extends Lead in Golden Lunch Bucket World Cup!’
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.
Continue reading ‘Tight Coding and Loose Coupling’
Bill Sanders
Recent Comments