Use multiple inheritance to discriminate useage roles?

Question

Hi fellows,

it's my flight simulation application again. I am leaving the mere prototyping phase now and start fleshing out the software design now. At least I try..

Each of the aircraft in the simulation have got a flight plan associated to them, the exact nature of which is of no interest for this question. Sufficient to say that the operator way edit the flight plan while the simulation is running. The aircraft model most of the time only needs to read-acess the flight plan object which at first thought calls for simply passing a const reference. But ocassionally the aircraft will need to call AdvanceActiveWayPoint() to indicate a way point has been reached. This will affect the Iterator returned by function ActiveWayPoint(). This implies that the aircraft model indeed needs a non-const reference which in turn would also expose functions like AppendWayPoint() to the aircraft model. I would like to avoid this because I would like to enforce the useage rule described above at compile time.

Note that class WayPointIter is equivalent to a STL const iterator, that is the way point can not be mutated by the iterator.

class FlightPlan
{
public:
    void AppendWayPoint(const WayPointIter& at, WayPoint new_wp);
    void ReplaceWayPoint(const WayPointIter& ar, WayPoint new_wp);
    void RemoveWayPoint(WayPointIter at);

    (...)

    WayPointIter First() const;
    WayPointIter Last() const;
    WayPointIter Active() const;

    void AdvanceActiveWayPoint() const;

    (...)
};

My idea to overcome the issue is this: define an abstract interface class for each usage role and inherit FlightPlan from both. Each user then only gets passed a reference of the appropriate useage role.

class IFlightPlanActiveWayPoint
{
public:
    WayPointIter Active() const =0;
    void AdvanceActiveWayPoint() const =0;
};

class IFlightPlanEditable
{
public:
    void AppendWayPoint(const WayPointIter& at, WayPoint new_wp);
    void ReplaceWayPoint(const WayPointIter& ar, WayPoint new_wp);
    void RemoveWayPoint(WayPointIter at);

    (...)

};

Thus the declaration of FlightPlan would only need to be changed to:

class FlightPlan : public IFlightPlanActiveWayPoint, IFlightPlanEditable
{
    (...)
};

What do you think? Are there any cavecats I might be missing? Is this design clear or should I come up with somethink different for the sake of clarity?

Alternatively I could also define a special ActiveWayPoint class which would contain the function AdvanceActiveWayPoint() but feel that this might be unnecessary.

Thanks in advance!

Answer 1

Not sure about "cavecats" ;-) but isn't the crew of the aircraft sometimes modifying the flight plan themselves in real life? E.g. if there is a bad storm ahead, or the destination airport is unavailable due to thick fog. In crisis situations, it is the right of the captain of the aircraft to make the final decision. Of course, you may decide not to include this in your model, but I thought it is worth mentioning.

An alternative to multiple inheritance could be composition, using a variation of the Pimpl idiom, in which the wrapper class would not expose the full interface of the internal class. As @Matthieu points out, this is also known as a variation of the Proxy design pattern.

Answer 2

From a strict design point of view, your idea is quite good indeed. It is equivalent to having a single objects and several different 'views' over this object.

However there is a scaling issue here (relevant to the implementation). What if you then have another object Foo that needs access to the flight plan, you would add IFlightPlanFoo interface ?

There is a risk that you will soon face an imbroglio in the inheritance.

The traditional approach is to create another object, a Proxy, and use this object to adapt/restrict/control the usage. It's a design pattern: Proxy

Here you would create:

class FlightPlanActiveWayPoint
{
public:
  FlightPlanActiveWayPoint(FlightPlan& fp);

  // forwarding
  void foo() { fp.foo(); }

private:
  FlightPlan& mFp;
};

Give it the interface you planned for IFlightPlanActiveWayPoint, build it with a reference to an actual FlightPlan object, and forward the calls.

There are several advantages to this approach:

• Dependency: it's unnecessary to edit flightPlan.h each time you have a new requirement, thus unnecessary to rebuild the whole application
• It's faster because there is no virtual call any longer, and the functions can be inlined (thus amounting to almost nothing). Though I would recommend not to inline them to begin with (so you can modify them without recompiling everything).
• It's easy to add checks / logging etc without modifying the base class (in case you have a problem in a particular scenario)

My 2 cents.