In C++, the existence of abstract base classes and virtual functions means that programs can call, or access, interfaces without knowing the class that provides the implementation. This is a useful mechanism that allows an implementation to be written some time after the interface has been defined. Such implementations are known as plug-ins.
In early versions of Symbian OS, such implementations were provided by polymorphic interface DLLs. This meant that all frameworks within Symbian OS that wanted to use plug-ins had to provide their own mechanisms for clients to discover and instantiate the available implementations.
ECom removes this duplication of functionality by introducing a generic framework that provides a single mechanism to:
register and discover interface implementations
select an appropriate implementation to use
provide version control for plug-ins
To show how ECom does this, let's recap the essentials of any plug-in system.
A client wishes to access an object to perform some processing. The specifics of this object are not known until run-time. The general characteristics of the processing are known, and are defined in an interface, but several variants of required processing could exist, which are provided by implementations that support the interface.
There are four clearly-defined roles in such a system.
the client that wishes to access services
the interface that defines how to request services
the interface implementation that provides the required processing
the framework that provides clients with access to the implementations
The relationships are shown in a UML diagram below:
The instantiation mechanism forms the backbone of such a system, and is responsible for providing the services that identify, and load the correct interface implementation at run-time. ECom is such a framework.
We'll now look at the system from the perspectives in turn of each of the interface client, interface implementation, and interface definition, before summarising the functions of the ECom.