Question

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

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.