ECom plug-in – in the lights of Strategy Pattern

When I started understanding ECom architecture of Symbian, I tried to map it with some design pattern from the GoF book. This way I found out that the Strategy Pattern described as one of the Behavioral Patterns is the closest match. Let me share my understanding with you.

First of all, let me tell you about the Strategy Pattern as it has been described in the GoF book. It says that we should use Strategy Pattern when we have a family of related classes differing only in their behaviors. The class diagram of a simple strategy pattern would be like the following:

What this diagram essentially depicts is that Context and Strategy work hand in hand to determine which ConcreteStrategy to pick up in the runtime. We may pass a ConcreteStratgy object to the Context constructor to achieve this.

This can also be achieved by creating a template class of Context and passing Strategy as a template parameter. This will, however, be at compile time. Hence it would increase the efficiency with the cost of larger code footprint.

Now let me dissect the ECom framework to describe how it can be mapped with the strategy pattern. We know ECom framework is built as a client-server architecture. We don't have to bother about the background processing that the server does. What all we need to understand is the client interface of the ECom. There is a singleton class called REcomSession which is the client side interface of the ECom framework. It has got several exported functions out of which ListImplementationsL (there are three overloaded version of it) and CreateImplementationL (there are twelve overloaded versions of it) are the most important one.

So, to map the ECom architecture with the Strategy pattern, we need to understand when a client application (read context in the Strategy pattern) tries to load a specific implementation (read ConcreteStrategy in the Strategy pattern), how the ECom framework resolves it.

To do that, let me delve into one of the CreteImplementationL function of the client interface of the ECom architecture. I have taken the following function:

EXPORT_C TAny* REComSession :: CreateImplementationL(TUid aInterfaceUid, Tuid& aDtorIDKey, const TecomResolverParams& aResolutionParameters)

To implement an application which takes the help of the ECom architecture, we need to call the above function (say for example, from a menu command). Now, the most important things we need to know to load the correct implementation, are the Interface ID and the Resolution Parametrs. These are there in the registration file of the ECom plug-in.
So, here lies the analogy between the ECom architecture and the Strategy Pattern.

1. .In strategy pattern, we have a strategy interface from where different strategies are realized. In ECom, we create an interface which are realized in different implementations.

2. .In Strategy, we pass the Strategy interface as a parameter to the context to load the correct implementation at runtime. The context object is created with the correct implementation of the Strategy interface. In ECom, we create the correct implementation by passing the Interface ID and the Resolution parameter from Client (read context) to the ECom framework.

3. .In strategy pattern, the client of the context must know what are the concrete strategies available for the current strategy interface. In ECom, the application must know what are the implementation we have for a specific interface. Of course we can query about it using ListImplementationsL, however, the knowledge must be available to the application.

So, in essence ECom plug-in architecture is some kind of application of the strategy pattern.