Monthly Archive for November, 2007

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.

Continue reading ‘The Flyweight Design Pattern: Where Shared Objects Solve Storage Problems’