This is part 1 of a two part composite pattern example implemented in ActionScript 3. The composite pattern comes in handy to develop complex structures consisting of simpler parts or components. The components can be primitive objects or they can be containers that hold other components. An example will help explain this better. Think of a house as a composite object. A house consists of a roof and several rooms (living spaces). Each room can contain windows, chairs etc. The house and rooms are composite objects as they contain other components. However, we can consider the roof, windows, beds and chairs as primitive objects. The composite pattern makes building, accessing, and manipulating composite structures simple by enabling the client to treat both composite objects (that contain other objects) and components (primitive objects) the same way through a common interface.
The following example develops a book in Flash. A book is a composite object as it contains several pages. This is by no means a functional book, but a conceptual example to illustrate the utility of the composite pattern. One of the big advantages of design patterns is extensibility: allowing the application to expand and add new features without breaking existing functionality. We will extend this example in part 2 by adding composite pages that can contain text and images.
Continue reading ‘Composite Pattern: Book (Part 1)’
Doug Crockford, Chief JavaScript Architect at Yahoo, did an excellent four part video series (each about 30 minutes long). Doug has a nice presentation style and covers most of the foundational elements of the language. There is a lot to learn here for ActionScript 3.0 programmers because of the common ECMA Script foundation in both languages.
Continue reading ‘JavaScript lectures’
Roger Braunstein has posted an excellent E4X primer at http://mimswright.com/blog/?p=141. He addresses a lot of the gotchas like setting the default namespace before parsing an XML node – something that drove me up the wall before I figured it out.
After my introduction to design patterns a few years back, I kept trying to find the sine qua non of design patterns. The more I looked, the less impressed I’ve become with the reasons for using design patterns and the more impressed I’ve been with design patterns themselves. That last sentence may sound like an oxymoron (and maybe it is), but it means that the more design patterns that I’ve used, the more sense they make. Still, such an endorsement hardly sounds like an articulate rendering of the “why” in design pattern usage. So I’d like to use this blog to articulate the reasons for using design patterns and invite others to contribute their comments on the topic in the hopes of clarifying what these reasons are.
Continue reading ‘Why Design Patterns?’
In AS2, declaring a constructor as private in a class prevented it from being instantiated. Unlike AS2, constructor methods cannot be declared as private in ActionScript 3.0. This killed the simple runtime check for abstract class instantation. Sho Kuwamoto, Senior Director of Engineering at Adobe describes the thought process behind the omission of private constructors in AS3.
A more creative approach to implementing abstract classes is necessary in AS3. The issue of preventing instantiation of abstract classes in AS3 has been looked into very throughly by several developers such as Tink and Mims Wright. The solution is quite simple, but how do we make sure that abstract methods have been implemented in subclasses as well? This post describes one solution (Mims has another) to this issue using the concept of type introspection in ActionScript 3.0.
Continue reading ‘Runtime Checks for Abstract Classes and Methods in ActionScript 3.0′
Bill Sanders
Recent Comments