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.
Friday, August 22, 2008
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 brains with new innovative ideas. It's really surprising to know how a worker in this field can ever feel depressed.
I think we need to seek the answers to this dilemma from within the organization.
We can easily assume that usually, people with an analytical bent of mind come to this IT industry. However, the path to becoming a good IT professional is full of bumpy rides.
I think the first and foremost thing for a software engineer is to seek the answer not only from the "How's" point of view but also from the "Why's" point of view.
We must encourage the inquisition that a newbie in the industry comes with. We must encourage software engineers to go beyond the routine work and seek something extra. That extra thing varies from person to person. Moreover, we must create an environment where a software engineer should feel proud of the organization he works for. Without that emotional bondage, it's difficult to get the motivation to work on any sort of innovative work with all our body, mind, soul, and even senses directed to it. And it's difficult to create such environments without Gurus.
It's all about mind games. I think we should stop thinking that salary and perks are the only factors to be doled out to motivate people. This way we can create some managers and workers, but not leaders and innovators.
I will tell you the reason for such a mindset to decipher Why...
When I joined NOKIA, India - I got a chance to see a different C++ dev framework - the S60 platform for Symbian.
There I found about the new concept called two-phase construction of a UDT
Everybody said - this is the norm - but nobody tried to decipher why this is the norm
So, my Why was nurtured to figure out this
And, I got it
When Symbian became a popular mobile OS, the mobile device had limited memory. And there was no template at that time to maintain smart pointer or auto pointer to tackle exceptions while constructing a large object
So, there was the answer
The two-phase construction was carefully introduced in the Symbian framework just to avoid the exception during the construction of large objects in the Symbian OS
I worked with NOKIA in 2007 and in 2008 I got the answer in Japan. I started studying Boost's library to answer such Whys' of C++ right inside Japan and then voila, the Boost library was introduced in the C++ standard library in the release of a brand new C++ in the year 2009.
Here goes a write-up by another sage that mentioned Swamiji's clarion call for the "Why's"
In search of Why...
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.
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.
Subscribe to:
Posts (Atom)