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.

This tutorial demonstrates how to create a flexible DLL that hides the actual implementation behind a factory class acting as a gateway between client and the DLL.

If you had seen the show "Growning Pains" you must remember in one episode, Mike got a newspaper delivery job and he didn't want to deliver any of the newspapers. So he "outsourced" those newspapers to his brother Ben. And the postoffice gave Mike about 5 bucks but Mike only gave Ben 2.5 bucks for remuneration, so he could get 2.5 bucks without doing anything. In postoffice's perspective, they gave Mike 5 bucks and 100 newspapers and no matter how Mike delivered those newspapers, as long as newspapers are sent on time, they will pay for Mike next time anyway(actually he messed it up in the end...). That is, the way Mike deliver newspaper is transparent to the postoffice. Mike could do it himself or let Ben to do this, or maybe Ben will also "outsource" his job to others, whatever.

Almost every software has state machines, It's one of those basic elements of the program. Different states of an object corresponding to different behaviors of it. The simplest state machine is likely the combination of if/else statements or switch/case statements within one class. It works! Absolutely! But what if we have 10 "if" and 10 "else"? Let's see what could the State Pattern do for us?