Friday, August 22, 2008

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 are the analogies 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.

Sunday, August 17, 2008

Depression in the IT Industry

I was terribly disturbed by the news of the Pune based techie who committed suicide due to work pressure. It is no less important news than the suicides of farmers in India.

Software is all about passion - tickling our brain with new innovative ideas. Its really surprising to know how an worker in this field can ever feel depressed. I think we need to seek the answers for this dilemma from within the organization.

We can easily assume that mostly people with analytical bent of mind come to this IT industry. However, the path to become good IT professionals is full of bumpy rides. I think the first and foremost thing for a software engineer is to seek the answer not only from "How's" point of view, but also from "Why's" point of view. We must encourage the inquisition that a newbie in the industry comes with. We must encourage a software engineer to go beyond the routine work and seek something extra. That extra means different to different people.

Moreover, we must create an environment where a software engineer should feel proud of the organization he works for. Without that emotional bondage its difficult to get the motivation to work on any sorts of innovative work with all our body, mind, soul and even senses directed to it. And its difficult to create such environments without Gurus.

Its all about mind game. I think we should stop thinking that salary and perks are the only factors to be doled out to motivate the people. This way we can create some managers and workers, but not leaders and innovators.

Friday, August 1, 2008

Failure - a boon in disguise

Yesterday I was reading an article about the importance of failure in life. If properly utilized, the knowledge that we gain from failure can propel us to a new life. I have come to know about it from my own software career.

I first tasted failure in the beginning of my software career. Let me share it with you.

I came into the software profession from a telecommunication background without proper knowledge of programming and other software related technologies. However, I was confident that I could make it. With my little knowledge in programming, I was sent to Singapore for an assignment. I was given a task which needed good knowledge of C programming. Hence I was not able to solve the problem as I used to during my student life.

This inability came as a huge shock. My confidence became abysmally low. I was really confused about the relevance of the engineering degree that I had. It, however, acted as a stimuli that I have to learn the necessary software skills.

It was not easy.......especially in those days without the help of internet, google and all other relevant technologies that we take for granted these days.

From that failure, however, I had learned a lesson. The lesson of perseverance. I knew that someday I will be able to achieve the necessary skills required for a software developer.

From that failure onwards I started reading whatever books related to software that I could lay my hands on. I knew my target but the path was still unknown. However, with sheer perseverance, patience and hard work, I was able to achieve my goal.

These days when I decipher different software codes, I say, THANK YOU to that FAILURE.

Share