Extrinsic States
In the first part of the Flyweight Saga, I had the idea that a Flyweight design pattern would be a good idea because it would be useful for cranking out buttons on the stage. However, the comments by the readers have led me to reconsider that idea; so it’s back to the drawing board. This revised Flyweight is going to focus on adding an extrinsic state parameter. Also, I got rid of all but one of the concrete Flyweights and am now down to the FlyButton class only in order to focus on extrinsic states.
Keep in mind that this process is a matter of working out the specific sense of a Flyweight pattern more than it is to show the optimum example. In going over some Flyweight materials from MIT, they suggested having a grasp on other, simpler patterns like the Observer and even MVC before tackling the Flyweight. This was both comforting and worrisome!
Extrinsic State Parameter
To get back on track (somewhat), this new Flyweight includes a parameter for extrinsic states in the Flyweight interface. Because the state is extrinsic, it changes with the Flyweights context. As discussed briefly in Part I of this saga, the extrinsic state changes with the context while the intrinsic state does not. Thus, the extrinsic state is not shareable (a shared object) and the intrinsic is. A concrete class can be sharable or not, but it cannot be if it does not store the intrinsic state. However, both sharable and non-sharable concrete Flyweights can exist. The following summary might be helpful.
Extrinsic state
Cannot be shared
Depends on flyweight’s context
Client is responsible for supplying extrinsic state when needed
Intrinsic state
Can be shared
Stored (inherent) in the flyweight
Does not depend flyweight’s context
Continue reading ‘The ActionScript 3.0 Flyweight Saga: Part II Extrinsic States’
I ran across the Flyweight design pattern when looking for a pattern that could be used to speed up placing objects on the stage in a Flash application using ActionScript 3.0. The Flyweight name implies a somewhat insignificant design pattern, but after working with it for a few months I found it to be both powerful and informative. It is powerful in that it is one pattern that actually speeds up operations, and it’s informative in that key OOP concepts are used and illuminated in it. It’s also one that has taken a while to really put together right—a process I’m still working on. Because this is a work in progress, I’d like to invite any and all developers with an interest in ActionScript 3.0 and design patterns to comment.
Continue reading ‘The ActionScript 3.0 Flyweight Saga: Part I’
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)’
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′
Our latest book is currently on O’Reilly rough cuts with expected publication in July 2007. This hands-on introduction to design patterns is for experienced Flash developers ready to tackle sophisticated programming techniques with ActionScript 3.0. The book takes you through the process step by step, explaining how design patterns provide a clear road map for structuring code that actually makes OOP languages easier to use. During the course of the book, you will work with many examples. We introduce design patterns with minimalist examples before going on to build full-fledged working applications.
Recent Comments