Free Flash & Flex Developer’s Magazines

Published
by
William B. Sanders
on July 1, 2009
in Design Patterns
. 2 Comments

Another Source for Some Good Design Pattern Information

I received an email from Ewa Samulska providing a link for downloading several issues of the magazine she edits, Flash & Flex Developer’s Magazine. You can get your PDF copies at http://www.ffdmag.com/prt/view/free-issues.html .

The magazine is written for three levels of developers—beginners, intermediate, and advanced. I’ve found useful information on all levels. I’m still getting used to the Flex IDE, and I’ll take any help that I can get on it, and I’m always willing to learn more about Flash. Many of the articles cover Flash and Flex used with other technologies or programming language, and that’s something else I find always helpful.

However, it was the MVC article I found that caught my interest in the 2/2009 issue. It’s a nice description of MVC and using the Cairgorm Framework. Anyway, poke around at the site, and you’ll find several issues you can freely download. Not only will you find the articles well-written, I liked the professional layout and graphics.

  • Share/Save/Bookmark

OOP Quote #1

Published
by
William B. Sanders
on June 26, 2009
in OOP Quotes
. 2 Comments

Every now and then I find a quote about OOP or Design Patterns that I constantly reference. Instead of popping them into a text file (as I now do) I decided to put them in AIR apps. Then I could make them look like those goofy employee inspiration quotes some companies plaster around the cubicles (e.g., “Soar like an eagle!”). However, instead of inspiration, I chose reminders of what it means to write good OOP or DP. They’re not exactly the same as principles (which are in another AIR app) but just good guides. You can download them here in AIR files.

Here’s the first one, which you may recognize from previous posts:

oopquote1

If you have any similar quotes that you find instructive, send them along with their source, and we’ll put them up.

  • Share/Save/Bookmark

Friends with Benefits: State and Factory Method Together at Last—Part II

Published
by
William B. Sanders
on June 24, 2009
in Design Patterns, Factory Method, Polymorphism and State
. 4 Comments

In the first part of this article, Friends with Benefits: Refactoring with Multiple Design Patterns—Part I you saw how a Factory Method design pattern was used to hold and deliver data to a DataProvider object. The Factory Method design pattern allowed for easy update by simply adding items to concrete products from a Product interface (DataSupply) or new concrete Product classes. New data can be added to the Concrete Products and the Client makes requests through the Creator interface. The request is filtered through the Concrete Creator to the Product interface to the concrete Product classes. Now, all we need to do is to refactor the player with a design pattern. However, before starting download the application (With 12 classes in the design patterns, a Client class plus three folders of videos, there’s a lot!) So first off, click here to Download All Files . You can see a working version of the player and multiple data sets here. These will help pull together all of the elements used in this project.

Here Comes the Big Bad State Machine

Before we get going on refactoring the video player application, we need to see where it will go in the context of both the State and the Factory Method design patterns. Figure 1 shows the relationship between the refactored player (State) and the factory that delivers the data (Factory Method).
dualdpfilessm
Figure 1: Files for two design patterns in class diagram

The images are organized in an “open” folder, and the videos are placed in separate folders showing their relative position to the classes making up the two design patterns. The Client makes a request through the Factory Method to populate a List component with data from a DataProvider. Then, the request from the Client to the player can be made through the List component by clicking on the video selection. Figure 2 shows what the final product looks like so that you can more easily follow the refactoring:
Continue reading ‘Friends with Benefits: State and Factory Method Together at Last—Part II’

  • Share/Save/Bookmark

Hello World! : The Second Golden Lunch Bucket Contest!

Published
by
William B. Sanders
on June 21, 2009
in ActionScript, Design Patterns and Design Patterns at Work
. 2 Comments

goldenbucketIt’s about time for another Golden Lunch Bucket Contest, and once again you can reap fame and fortune! (And again, we’ll provide the former if you provide the latter. This time, though, we must insist that you provide better prizes for yourself if you’re one of the winners!)

If you’re feeling lucky, then enter the contest. Who knows? You might just win, and then you can go nuts! We know, you’ll have to put up with the paparazzi and the inevitable groupies, but that’s just the cost of fame. (Our former winners will give you advice on how to handle it all.) Just remember Dirty Harry’s advice:

You gotta ask yourself one question: Do I feel lucky? Well, do ya, punk?

What is it?

In more than one post by design pattern enthusiasts, I’ve seen warnings against Design Pattern Fever with dire warnings about using design patterns for petty projects. Well, I don’t agree! From our survey, we found that while most would like to include good OOP and design patterns in their projects at work, most good programmers are under so much pressure to get the job done that they don’t have time for design patterns. So instead of kick-starting your design pattern work with a big project, start small with a Hello World! project.

The goal is to use a design pattern (any one you want except the Singleton) to output “Hello world!” in eight (8) different languages. In our last contest, we had winners from all over the world, and so having more than one language seems appropriate. (You get bonus points if one of the languages is Icelandic, Yoruba or Navaho.) The contest is from when you read this post until July 15, 2009. So get cracking and get lucky!

The Rules

  1. You must use a Design Pattern from the original Gang of Four’s book
  2. All entries must use ActionScript 3.0
  3. Either Flash or Flex formats are acceptable
  4. You may not use a Singleton design pattern (They’re pathological liars—that’s why.)
  5. The screen output must show “Hello World” in eight (8) languages—either separately or all together. You cannot use trace() statements for the output, but all output must be visible on the screen.
  6. You must specify which design pattern(s) you are using.
  7. Extra points are given for Icelandic, Yoruba and Navaho
  8. All entries must be in by July 15, 2009
  9. All entries must be placed in a ZIP file. (Nothing fancy for my Mac)
  10. Send entries to wdsanders@comcast.net with the subject line Golden Lunch Bucket Contest #2
  11. Include your name, age, where you’re from, and a 100 x 100 jpeg/png photo

Remember, you can use any design pattern you want with the exception of the Singleton (shudder). This is a simple contest, and there’s no pressure—you’ve got until July 15! So grab that can of Red Bull and hop to it!

  • Share/Save/Bookmark

Friends with Benefits: Refactoring with Multiple Design Patterns—Part I

Published
by
William B. Sanders
on June 16, 2009
in ActionScript, Design Patterns, Examples, Factory Method and State
. 4 Comments

The Case of the Crowded Client

After I made my video player that I planned to use to illustrate refactoring a non-design pattern program into a design pattern one, I noticed how crowded the Client class had become. Most of the crowding was caused by creating and populating UIs and event handling functions. One class that I use a lot to populate UI components is the DataProvider. As I went through and edited and organized my videos from a vacation to Prague, CZ, the DataProvider kept growing. Using MP4 files converted into F4V files, I used very similar formats for the data portion of all of the DataProvider instance. Why not put the DataProvider data into a separate class? Then, I could just call an instance of the class with the data and not have to clutter the Client class with messy DataProvider information.

Lazy Programming can be a Lot of Work

After moving the DataProvider data to another class, I realized that I had two other projects using the video player that accessed the same kind of data. So, while I was at it, I might as well add classes for these other projects. In fact, why not add a common interface as well? Then I could program all data requests to the interface instead of the implementation. Further, I could add some separation between the DataProvider items and the Client requests by adding a factory, and if I were going to do that, I might as well go ahead and create a Factory Method design pattern. Then, whenever I wanted to add a class with data for different projects I could do so without having to worry about messing up the rest of the program. Each project was handled using a Concrete Product class.

The Big Picture

To begin with a clear idea of what is going on in this refactoring exercise, you’ll need to get the big picture. Figure 1 provides an overview of how the video player is to be refactored using two design patterns:
twodps1

The video player is essentially a state machine, and in Part II of this post, we’ll look at how we’ll refactor the hack-job player into a state player.
Continue reading ‘Friends with Benefits: Refactoring with Multiple Design Patterns—Part I’

  • Share/Save/Bookmark