Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


Multiple inheritance and interfaces

[Top]


Overview

Multiple inheritance is a powerful aspect of C++. Experience of multiple inheritance indicates that its benefits are best realised by carefully controlling the ways in which it is used within a system to a few easily understood paradigms. Use of multiple inheritance without such control has usually led to designs that are difficult to understand.

Multiple inheritance is used for a single purpose in Symbian OS: namely, interface protocol definitions. These are used in the following kinds of situation: there is a protocol provider class, and a protocol user. It is desirable that the protocol user be independent of all aspects of the protocol provider, except its ability to provide the specified protocol. Examples of such situations include:

To understand why interfaces are used, this page examines in turn:

[Top]


Protocols using classic single inheritance

A classical use of single inheritance is to define an abstract protocol from which derived classes may inherit. A base class defines a protocol:

class CProtocol : public CBase
    {
public:
    virtual void HandleEvent(TInt aEventCode)=0;
    };

The protocol includes just one function, HandleEvent(), where the event is defined by an integer event code.

A concrete protocol provider class is then derived from this base class. It provides a concrete implementation of the pure virtual function in the base class:

class CProtocolProvider : public CProtocol
    {
public:
    // construct/destruct
    static CProtocolProvider* NewLC();
    void Destruct();
    // implement the protocol
    void HandleEvent(TInt aEventCode); // handle protocol
protected:
    void ConstructL();
    };

In addition, there is a protocol user class which knows nothing about the derived CProtocolProvider class, but it does know about the CProtocol class and the functions that specify its protocol. It has a function which uses HandleEvent():

void CProtocolUser::DoSomething(CProtocol* aProtocol)
    {
    _LIT(KOutput1,"External system doing something\n");
    _LIT(KOutput2,"invoking protocol - event 3\n");
    testConsole.Printf(KOutput1);
    testConsole.Printf(KOutput2);
    aProtocol->HandleEvent(3); // handle an event
    }

The virtual function defined by CProtocol is provided by CProtocolProvider. This is the virtual function that is actually executed:

void CProtocolProvider::HandleEvent(TInt aEventCode)
    { // handle an event in the protocol user
    _LIT(KOutput1,"CProtocolProvider handling event %d\n");
    testConsole.Printf(KOutput1,aEventCode);
    }

Thus, although the protocol user knows nothing about the derived CProtocolProvider class, it can invoke its member functions through a pointer to its derived class, using the C++ virtual function mechanism.

This code may be used in the following way:

void doExampleL()
    {
    // show use of interface with simple class
    CProtocolProvider* provider=CProtocolProvider::NewLC();
    CProtocolUser* user=CProtocolUser::NewLC();
    user->DoSomething(provider);
    CleanupStack::PopAndDestroy(); // user
    CleanupStack::PopAndDestroy(); // provider
    }

In the function call, the provider pointer is cast to its CProtocol* base class, as required by CProtocolUser::DoSomething().

The advantages of this method are

This was the goal we set out to achieve. However, this method has a serious disadvantage:

The straightforward method of providing protocols by strict single inheritance often leads to large base classes, representing many protocols which should really be independent of one another.

[Top]


Protocols using an intermediate class

Some of these disadvantages can be overcome by using an intermediary object which represents the protocol, and has a pointer to the protocol provider. The base protocol class is essentially the same:

class TProtocol
    {
public:
    virtual void HandleEvent(TInt aEventCode)=0;
    };

but there is now a derived class for use with the CProtocolProvider only:

class TProtocolProviderIntermediary : public TProtocol
    {
public:
    // construct
    TProtocolProviderIntermediary(CProtocolProvider* aRealProvider);
    // protocol itself
    void HandleEvent(TInt aEventCode);
private:
    CProtocolProvider* iRealProvider; // real provider
    };

This class provides the protocol as far as the protocol user is concerned. The concrete implementation of HandleEvent() just passes the function call to the real protocol provider class, which has a non-virtual DoHandleEvent() to provide the required functionality:

void TProtocolProviderIntermediary::HandleEvent(TInt aEventCode)
    {
    iRealProvider->DoHandleEvent(aEventCode);
    }

With this system, CProtocolProvider is derived, not from the protocol definition class, but from CBase:

class CProtocolProvider : public CBase
    {
public:
    // construct/destruct
    static CProtocolProvider* NewLC();
    void Destruct();
    // implement the protocol
    void DoHandleEvent(TInt aEventCode); // handle protocol
protected:
    void ConstructL();
public:
    TProtocolProviderIntermediary* iProviderIntermediary;
    };

The TProtocolProviderIntermediary is constructed by the CProtocolProvider’s constructor, and destroyed by its destructor. For this reason, the TProtocolProviderIntermediary is a T class: it does not own the CProtocolProvider, and cannot be orphaned.

When a function in the protocol user requiring the protocol provider is called, it must now be called passing the intermediary object as a parameter:

LOCAL_C void doExampleL()
    {
    // show use of interface with simple class
    CProtocolProvider* provider=CProtocolProvider::NewLC();
    CProtocolUser* user=CProtocolUser::NewLC();
    user->DoSomething(provider->iProviderIntermediary);
    CleanupStack::PopAndDestroy(); // user
    CleanupStack::PopAndDestroy(); // provider
    }

The protocol user’s DoSomething() is essentially as it was before, except that its parameter is now a TProtocol*. Thus, the user knows only about the base TProtocol class. The virtual function mechanism causes the derived intermediary’s HandleEvent() to be called, and this function passes on the request to the real protocol provider’s DoHandleEvent().

This method solves the problems associated with using only single inheritance:

However, it has a serious disadvantage:

[Top]


Protocols using interface classes

These problems can be overcome by using multiple inheritance. A base MProtocol class specifies the protocol:

class MProtocol
    {
public:
    virtual void HandleEvent(TInt aEventCode)=0;
    };

This time, however, the protocol provider is derived both from CBase and from MProtocol:

class CProtocolProvider : public CBase, public MProtocol
    {
public:
    // construct/destruct
    static CProtocolProvider* NewLC();
    void Destruct();
    // implement the protocol
    void HandleEvent(TInt aEventCode); // handle protocol
protected:
    void ConstructL();
    };

The protocol provider class provides a concrete implementation of the HandleEvent() function required by the protocol. The user class may now be invoked as follows:

LOCAL_C void doExampleL()
    {
    // show use of interface with simple class
    CProtocolProvider* provider=CProtocolProvider::NewLC();
    CProtocolUser* user=CProtocolUser::NewLC();
    user->DoSomething(provider);
    CleanupStack::PopAndDestroy(); // user
    CleanupStack::PopAndDestroy(); // provider
    }

The DoSomething() function requires an MProtocol* parameter. C++ casts the CProtocolProvider* provider pointer down to an MProtocol*, because MProtocol is one of the base classes of CProtocolProvider. When DoSomething() invokes HandleEvent(), the C++ virtual function mechanism ensures that it is CProtocolProvider’s HandleEvent() that is actually called. Thus, the user may use the protocol, without knowing anything specific about the concrete protocol provider class.

This method achieves the intended goals:

Because protocols may be mixed into the derivation hierarchy of conventional classes at any convenient point in the hierarchy, such protocol specification classes are sometimes also called mixins, the origin of the prefix M.

[Top]


Restrictions on the use of multiple inheritance

The use of multiple inheritance is restricted to interfaces used as described above. C++’s full multiple inheritance facilities are unnecessarily complex. This is perhaps recognised by the OO community now. Java, for instance, allows only single inheritance, but the interface and implements keywords support the same facilities as are provided by M classes. The restrictions are given in more detail here.

Firstly, M classes primarily define protocols, not implementations. In particular, they should not have any member data. The restriction implies that certain types of behaviour (e.g., that of active objects, see Active objects) may not be encapsulated in an interface, but must be derived in the conventional way.

Secondly, a C class may be derived from one other C class, and zero or more M classes. This restriction reflects the fact that multiple inheritance is only to be used for interfaces. It implies that it is still possible to uniquely identify a primary inheritance tree (the C class hierarchy), with interfaces as a side feature. If arbitrary multiple inheritance were allowed, it would be impossible to identify a primary inheritance tree. The restriction also guarantees that no C class will be a multiple base class, which makes it unnecessary to consider the complications of multiple base class inclusion, virtual inheritance, etc.

Thirdly, the C class must be the first specified class in any base class list. This emphasises the primary inheritance tree and, importantly, it makes conversions between any C class (including those with interfaces) and void* pointers freely possible. Admittedly, the C++ standards do not mandate that object layout follows the order in which base classes are specified, but in practice this is the case for most compilers, including those used for Symbian OS.

Fourthly, no M class may be mixed in more than once in any class, either as a direct base or as a base of any of its primary base classes. To put it another way: when deriving a C class CD from a base class CB, you may not mix in any M class MP which has already been mixed into the derivation of CB. This reflects the fact that CB already supports the protocol defined by MP: there is nothing to gain from mixing in this protocol class again. In addition, it makes it unnecessary to consider the complications of multiple base class inclusion, virtual inheritance, etc.

Finally, although it is legal to derive one M class from another, it is not legal to include a protocol twice by including both it and a derived protocol into a C class, at any point in the C class’s base class graph. To put it another way, if there is a class MD derived from MB, then a C class cannot include both MB and MD. This is because any function in the C class which provided an implementation of MB protocol could conflict with the implementation of MD protocol.

[Top]


Example uses


Callbacks

A special case of an interface is the callback. In this situation, one class performs a certain function for another and, when this is done, calls a single function in the requesting class, to indicate that the requested operation is complete. This call-back function represents a protocol: the requesting class is the provider, and the performing class is the user. Apart from this, the performing class need know little or nothing about the requesting class. This is an ideal situation for a interface.


Two-way use

So far, we have discussed interfaces in the context where one class provides services according to a given protocol, and another uses those services. In a more general case, two classes (or systems of classes) may require services from each other, so that there is two-way interaction.

Services are always provided according to a protocol. The protocol can be provided using any of the techniques described in this document:


Observers

GUI applications use menus to present a user interface for selecting options. When an option has been chosen, the menu bar should forward a command somewhere by calling a member function of some class. The only thing that is important to the menu bar is that some object exists which can handle the command: beyond that, nothing matters about the object.

class CEikMenuBar ...
    {
public:
    ConstructL(MEikMenuObserver* aObserver, ...);
    // ...
private:
    MEikMenuObserver* iObserver;
    // ...
    }

A menu bar therefore uses a menu observer. This is passed in as a parameter at construction, stored as member data, and used when an option has been selected. The menu observer interface is defined by the menu component, as the MEikMenuObserver class.

This interface is implemented by the app UI (which also does many other things, which are irrelevant to menus). So, CEikAppUi implements menu observer interface by deriving from MEikMenuObserver:

class CEikAppUi : public CCoeAppUi, MEikMenuObserver

The app UI has a menu bar, and when it constructs the menu bar, the app UI passes itself to the menu bar, as the observer:

iMenuBar->ConstructL(this, ...);

C++ causes the this to be cast into the appropriate base class—in this case, an MEikMenuObserver—automatically.