Note: After three Flyweight Saga entries, I think I have all of the parts explained and working like they should. To double-check, the following was presented at the 2007 OOPSLA conference in Montreal. The great comments that the readers of this blog provided were most helpful, and further comments by those in the OOPSLA Killer Examples session all added to what I hope works to clarify using the Flyweight Design Pattern with ActionScript 3.0. Also, everything in this article is based on Design Patterns Elements of Reusable Object-Oriented Software by the Gamma, et al.
Air traffic controllers look at virtual simulations of hundreds of aircraft. The images on a screen give the ATCs the information they need for separating the many planes under their control. The hub airports such as Chicago O’Hare and Dallas-Ft. Worth have to juggle hundreds of simultaneous flights arriving at and departing from their respective airports. To maintain accuracy, images that display position, heading, altitude, level flight, ascent and descent must be updated frequently, accurately and quickly. In looking over the set of design patterns set forth by Gamma, et al, the Flyweight pattern offers the following:
- An application uses a large number of objects
- Storage costs are high because of the sheer quantity of objects
- Most object state can be made extrinsic
- Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed
- The application doesn’t depend on object identity. Since flyweight objects may be shared, identity tests will return true for conceptually distinct objects
That pretty well fills the bill for what is required. We need a large number of objects (airplane images), the sheer quantity has high storage costs, the extrinsic state such as heading, horizontal position and vertical position can be made extrinsic, once extrinsic state is removed, a few objects can be used to represent groups of objects, and the application is not dependent of object identity. This is not to say that one cannot be distinguished from the other, but rather the object identity is relative to its extrinsic characteristics.Figure 1 shows the basic class diagram.
Figure 1: Class Diagram
The key elements of the class include the following:
- The Flyweight class, (an abstract class or interface) with the operation with parameters for the extrinsic states.
- A Flyweight Factory that aggregates the Flyweight class. (The ball at the end of the aggregation arrow indicates that multiple aggregations may exist.)
- A Concrete Flyweight contains the extrinsic states and the intrinsic states. This is a shared object
- (Optionally) An unshared concrete Flyweight containing the extrinsic state but cannot be shared.
- A Client participant. The Client class in this design pattern has a responsibility and has acquaintance relations with both the concrete flyweights and the factory classes.
Read more…
Aggregation Aggravation
In the first installment of this Flyweight Saga, I noted that the relationship between a Flyweight and Flyweight Factory class is one of aggregation. The initial example shows that the Retrieve method in the Factory class returns an instance of IFlyweight, meeting the requirement of the proper connection between the two classes. In looking at one example in Java, (even with modest Java skills), the program clearly did not have such a relationship between the Factory and Flyweight. In fact, it claimed, that an object’s extrinsic state can be shared by classes. Now, maybe that was unfortunate wording because the big feature of the Flyweight design pattern is that the Flyweight can be a shared object, but only the intrinsic state can be shared. (Maybe the author meant that extrinsic states can be shared between classes in a Flyweight design pattern, and that’s probably right but is not a key feature of the pattern.)
Read more…
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
Read more…
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.
Read more…
Bill Sanders
Recent Comments