Applying the Mediator design pattern in Flex

Any complex screen, more or less, of a business application consists of a number of containers (Panel, Canvas, VBox) and controls (Buttons, DataGrids, Comboboxes). In the best case scenario, a UI designer gives you a nice looking screen prototype that s/he put together without bothering too much about what Flex components are you going to select to implement the required functionality. Now what? Just look at this screen below that consists of a number of nested components and containers, which I numbered for easier reference. For simplicity (or should I say for better abstraction?) I did not use the actual components like panels and dropdowns, but I’m sure you can extrapolate this image to your real world business screen.

A simple (but wrong) approach is to just put all these components in one container (1), program the business logic and communications between these components and be done with it. This would produce a monolithic application with tightly-coupled components that know about each other and removal of one component would lead to multiple code changes in the application. Talking about string attached…

The better approach is to create loosely-coupled custom components that are self contained, do not know about existence of each other and can communicate with external world by virtue of sending and receiving events. Adobe Flex is a good tool for creating event-driven applications, and it has all you need for creation of custom components. At this point, I could have just explained you the essence of using custom components, but I’d rather make this essay more solid by introducing a little bit of a theory of object-oriented programming and explain you the use of the design pattern called Mediator. People say that these days some smart employers are ask questions about design patterns during job interviews. So let’s get armed with the pattern called Mediator.
We’ll start with a definition of this pattern from Wikipedia :

“The mediator pattern is a software design pattern that provides a unified interface to a set of interfaces in a subsystem.”

Not clear? I know. Keep reading.

“The mediator pattern addresses this problem by promoting looser coupling between these classes by being the only class that has detailed knowledge of the methods of other classes. Classes send messages to the mediator when needed and the mediator passes them on to any other classes that need to be informed.”

This does not get much better either.

OK, to put it simple, if you have Lego parts, they do not know about each other and they do not have an idea that some boy (a.k.a. Mediator) has decided to use these particular components to build a toy house. And tomorrow, the Mediator will decide to use the same components in a boat. You know where I’m going to with all this…

I would expect that some impatient readers have already scrolled down this article to see if I’ll ever show you some concrete code examples. I will. Promise.
In the diagram above, containers play the role of the Mediator. The top level mediator is the container 1, which is responsible for making sure that the components 2, 3, and 6 can communicate if need be. On the other hand, the number 2 is a mediator for 4 and 5. The number 3 is the mediator for 7 and 8.
Being a mediator is a very honorable mission, but it comes with responsibilities – you need to listen to events from one of your Lego parts and, possibly fire the event on the other one.
For example, in the online store scenario, the number 6 can be a control where you select an item, number 4 is the button “Add To Shopping Cart” and 5 is a shopping cart. Let’s forget about the number 6 for a moment and look at the content of the mediator number 2. The button 4 has a specific look and fill and can do just one thing – broadcast the event “AddItemClicked”. To whom? To whoever’s interested in receiving such an event.
So expect to have a code

dispatchEvent(new Event(“AddItemClicked”))

somewhere inside the component 4. If the mediator 2 is interested in receiving of this event (and it is, otherwise why even bother including number 4?) it will define an event listener for it, which will get the event and in turn will dispatch another event right on the number 5:

addEventListener(“”AddItemClicked”, addItemClickedEventHandler)

private function addItemClickedEventHandler ():void{
Number5.dispatchEvent(new Event(“Add2ShoppingCart”));
}

Please note, that in the pseudo-code above, the mediator is choreographing the show – how its little components will communicate. It’s time to go to nitty-gritty coding details. Just read an article about creating custom components in Flex.

I’d like to stress that in the above example the number 4 is shooting an event up in the sky – listen whoever wants to hear. On the other hand, the number 5 is just sitting quietly and listening to the incoming event. From whom? It has no idea. This is what I mean by loose coupling of components. The number 4 does not know about the number 5, but they talk anyway through the mediator.
But as a developer of this screen, you have to take care of mediator-to-mediator communications as well. For instance, if the number 6 is a widget where you can select your Sony TV, the mediator 1 will be notified about it and need to talk to the mediator 2, which in turn will arrange the flow between 4 and 5.

The bottom line

Do not even think of starting coding UI unless you’ve identified your mediators, custom reusable components and all communications between them via events.

Regards,
Yakov Fain

One thought on “Applying the Mediator design pattern in Flex

  1. I was wondering:

    why wouldn’t you use

    private function addItemClickedEventHandler ():void{
    Number5.add2ShoopingCart(someNecessaryData);
    }

    ?

Comments are closed.