One of the principles of Object Oriented Programming and Design Pattern Architecture is the idea of programming to interfaces rather than concrete implementations. The word interface here does not necessarily imply the interface programming structure rather, the idea of programming to a super class or to an interface. The idea is simple - if class A is the super class of class B, class C and class D, then a variable a:A can contain A, B, C or D.
var a:A = new A;
a = new B();
a = new C();
a = new D();
This is actually in its very basic form, the main scaffolding of a Finite State Engine.
Recently I had to deal with creating accessible structures for an application. I was faced with the option of creating separate listener methods for MouseEvent.ROLL_OVER, and FocusEvent.FOCUS_IN in spite of the fact that they did the same thing. The solution was to 'Program to an interface'. In this case, the Event class is the interface or superclass of all the events. Therefore rather than have the listener method parameter datatyped to the concrete type, it was datatyped to the super class. The result is that you can set all the subscriber objects to listen to the same listener method.
a.addEventListener(FocusEvent.FOCUS_IN, interfaceHandler);
a.addEventListener(MouseEvent.ROLL_OVER, interfaceHandler);
public function interfaceHandler(e:Event):void{
Dowhatneedstobedone();
}
Bugbears is finally live. The application developed for CBBC provides children with a platform to air their views on a number of topics anonymously. They are provided a voice recording studio where they can select a creature to which their recorded voices would provide the voice track. An animated creature is then created and posted to the site. Visitors to the site can play back these 'bugbears' and tag then with 'hugs', 'respect' or 'feel the same'. A few more features on the site provide the visitor with the ability to leave advice or feedback on the various subjects.
This CBBC project has taken half of the year in development and required nay demanded my complete attention over the time. For the most part it as been 1 long 6month week with lots of 48 hour development sessions generously sprinkled with lots of hair pulling and head scratching and very hairy moments. Lots of lessons have been learned during the process from development and project management perspectives. All I can say is that I now know what it must be like to be a shirt in a washing machine in a hot wash. Nonetheless it has been a wonderful experience and seeing the project develop from use-case diagrams to release version has made all the work well worth it. My colleague and co developer Valentyne Derkach has been a boon and a dream to work with and I often wonder what it would have been with out him on board. Valentyne you rock!!
On a personal note this project allowed me to test the efficacy of MagicMVC (an mvc based scaffolding I developed for Magic Lantern Productions) and explore the possibilities offered by a Finite State Engine and the State design pattern. Indeed the Bugbears application is a Finite State engine managing a number of states (views) which are pulled in at the users request. It provided scaleability and robustness to the application and allowed us to deal comfortable with team development and the constant stream of changes to the application spec which inevitably come as the application was being developed. The use of an interface for state change rather than the use of concrete classes provided the flexibility to manage the intricate retrieval and removal of various classes required to make the system work.
Magic MVC provided the scafolding for tthe large views and because it provides a Flash Media Server hook in its model it allowed us manage NetConnections and Nestreams very comfortably. There is still a lot to be learned and as we put the in finishing touches, Val and I muse over how much better the site could have been if we had done things differently, if we had more time, if we planned better. I guess this is a good thing as it shows we are still developing and are searching to improve. We hope to release MagicMVC in the near future, as we have both found it very useful.
I'm a great fan of the Strategy Pattern. Its one of those "good ideas" of OOP thats seems so basic you wonder why you never thought of it before. The problem with employing Strategy for me has always been the best way to achieve interclass communication without compromising their loose coupled architecture. My great escape has always been the MVC triad since it is a compound of the Strategy, Composite and Observer pattern (Smalltalk). Then there is the option of a Delegation Event model - nicely explained by Mr Moock in his AS2 tome.
However the the "Daddy" of all the alternatives is the
Mediator. Simply put, "The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly." Loose coupling between each class is achieved by having the classes communicate with the Mediator, rather than with each other.
It works at its most rudimenary in the following fashion, ClassA is composed of a couple of classes, ClassB and ClassC. The nature of the application requires that instructions need to be passed from B to C, yet they need to remain completely independent of each other. Enter the Mediator, that "mediates" between both B and C by standing as an intermediary and passing instructions from B to C and vice-versa.
The only "fly in the ointment" is the fact that Mediators do not seem to be very reusable, but then neither are Models.
Over Christmas I've had the opportunity to play with a few of my favourite API's, Flash Media Interactive Server, Papervision3D 2.0 et al. A lot of my experiments have been done in one class, trying to navigate my way around new tools and concepts. However this is not the way I like to work. The thought has been gnawing at my soul as to how these experiments would work if developed in a structured manner with a design pattern. What sort of problems would I face? Would there be scope issues? Would somethings just not work? To answer these questions, I developed a simple mp3 playlist which streams the songs from Flash Media Interactive Server. I have added to this a visualizer made with Papervision3D. To make it scalable and to allow me test a variety of iterations of my code I have chosen to base the application architecture on the Strategy pattern. Thus each view is a different strategy made of an MXML/AS3 control that implements a View interface. Thus to change the iteration of my display all I need do is implement a new Strategy. I do love patterns. I like the results and more the point it confirms that I can develop with these API's in the manner I prefer to work.
*An interesting point to note was the effect the wmode attribute had on publishing the swf. In some instances wmode will affect the display and performance of the swf. In this case it made all the animation respond only to Mouse actions. Removing the wmode gave me back my intended behaviours. Using these APIs though unfortunately create huge files and can be very CPU intensive so limitations have to be place on what effects can be used and so on. None the less it is gratifying.
