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.)
Anyway, after looking at several different descriptions of aggregation, including the one provided by the GoF, it’s clear that the concept is one with fuzzy borders and can slip into either general composition or acquaintance. It implies that the Flyweight Factory aggregates the Flyweight—no Flyweight, no Factory. As a result, the life of the aggregator (Flyweight Factory) depends on the life of the aggregatee (Flyweight). Like acquaintance, aggregation is implemented with references or pointers rather than defining variables of once class in another. (Apparently C++ is an exception and does set up aggregation by defining variables from the aggregatee class.)
By and large the issue has not been especially significant so far because all of the output was using trace statements, and so output was largely confined to built-in features that only work when the code is run in test mode. It’s great for debugging up to a point, but developing with trace statements that do not take into account how certain graphic elements, especially those that are accessed by extending the Sprite classes, can generate unusable structures for applications that employ graphics and other elements that require the import and extension of other classes. In this next Flyweight example, we leave the realm of trace and use the graphics property (from the Sprite class) to draw solid balls using fill methods. The ball class extends Sprite and implements the interface. That’s all fine and good, but the aggregation becomes problematic in even the simplest example. In taking the general structure from the examples examined up to this point (Parts I and II of the Flyweight Saga), we can begin to see the trouble.
Continue reading ‘The ActionScript 3.0 Flyweight Saga: Part III Aggregation Aggravation, Stuff on the Stage and the Intrinsic State’
This is a testimonial of sorts for the capacity to easily change an application created with design patterns. Recently Adobe put up a version of a player that streams H.264 formats–these are files like Apple’s .mov and MP4, among others. After fumbling around for a while creating the files–one video .mov using iMovie and a M4a audio using Garage Band, I went to test them on a progressive download app I had handy that was set up to play audio using the Sound class and video with NetConnection(null) and NetStream. The only problem was that the streaming audio (m4a) file required a NetStream instance and would not work with the Sound class.
Because the classes for handling audio were set up around the Sound class, I thought this would be a major chore, but all I had to do was to make changes in one class. After the changes were made, it worked fine. The best part is that the structure of the Template Method did not interfere with any of the other elements in the application. So while the application may be fairly complex for the simple task of playing video and sound, when things change, as they always do, making the changes in the application were simple.
The application can be found at: http://www.sandlight.com/player9/. Keep in mind that no FLV files are used but that a genuine MOV file being played in Flash using progressive download and the sound is from a M4a file, the same file format as the ones used for iTunes–all sitting fat and happy and working. You’ll need to go to Adobe Labs and download the Flash 9 player (Beta) to see this at work.
Video of Lee Brimelow’s session from AIR Camp Denver. Lee does a fantastic job of placing Adobe Air in the crowded field of Flash, Flex, Microsoft’s Silverlight and desktop apps. He demos several apps showing the capabilities of AIR apps including custom chrome and most importantly, the impressive speed of AIR apps running on the desktop, including several that use the Papervision3D library. He also shows how to create AIR apps using the excellent AIR Panel developed by the folks at gskinner.com (Note: Adobe now has an update for creating AIR apps from Flash CS3).
AIR opens a whole new discussion about best practices on developing desktop apps integrating ActionScript, HTML, Javascript and PDF and how to integrate design patterns that work seamlessly across multiple development frameworks.
This is part two of a two part series on developing the structure of a book using the composite pattern. In part 1, we treated pages as primitive component objects. However, pages can be further decomposed to contain text blocks and images. This example illustrates the utility of the composite pattern by demonstrating how easy it is to extend an application that implements the composite pattern by adding new composite and component classes that extend existing ones.
Continue reading ‘Composite Pattern: Extending the Book to include Composite Pages (Part II)’
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’
Recent Comments