Question

When I want to add functionality to this structure, without changing it:

class MemberBase
{
public:
    virtual MemberBase* clone() const; 
    virtual void action1(); 
    ... 
}

class Container
{
public:
    virtual void functionUsingAction1();
    ...
private:
    std::vector<MemberBase*> members_
}

I can subclass MemberBase and

class MemberType1 : public MemberBase
{
public:
    MemberBase* clone() const;// Reimplementation
    void action1();           // Reimplementation
    virtual void action2();   // New functionality
}

I can fill the container with the desired type of data by employing the

MemberBase* MemberBase::clone() const;

Method. But how do I call

void MemberType1::action2(); 

from the methods of the Container class? I can use dynamic_cast, but that is considered a design flaw. Is there any workaround? Or better, any pattern I can follow?

Answer 1

Honestly, the more I look at it and it looks like a typical Visitor application to me.

I would suggest avoiding implementing any intelligence in your Container class, and instead delegate the actions to a specific Visitor class. The base Visitor can be given some way to safely interact with the underlying container structure (erase/insert).

// MemberBase.hpp
class Visitor;

class MemberBase {
public:
  virtual MemberBase* clone() const = 0;

  virtual void accept(Visitor&) = 0;
  virtual void accept(Visitor&) const = 0;
}; // class MemberBase

// Visitor.hpp
class Member1;
class Member2;

class Visitor {
public:
  virtual void visit(Member1&) = 0;
  virtual void visit(Member1 const&) = 0;

  virtual void visit(Member2&) = 0;
  virtual void visit(Member2 const&) = 0;
};

// Container.hpp
#include <MemberBase.hpp>

class Container {
public:
  void accept(Visitor& v) {
    BOOST_FOREACH(MemberBase& mb, _members) {
      mb.accept(v);
    }
  }

  void accept(Visitor& v) const {
    BOOST_FOREACH(MemberBase const& mb, _members) {
      mb.accept(v);
    }
  }

private:
  boost::ptr_vector<MemberBase> _members;
};

Then you need to implement the member’s accept methods. It’s purely mechanical.

// Member1.hpp
#include <MemberBase.hpp>

class Member1: public MemberBase {
public:
  virtual Member1* clone() const { return new Member1(*this); }

  virtual void accept(Visitor& v);
  virtual void accept(Visitor& v) const;
};

// Member1.cpp
#include <Member1.hpp>
#include <Visitor.hpp>

void Member1::accept(Visitor& v) { v.visit(*this); }
void Member1::accept(Visitor& v) const { v.visit(*this); }

And finally you can implement a visitor:

// CountVisitor.hpp
#include <Visitor.hpp>

class CountVisitor: public Visitor {
public:
  CountVisitor(): _count(0) {}

  size_t count() const { return _count; }

  virtual void visit(Member1&);
  virtual void visit(Member1 const&);

  virtual void visit(Member2&);
  virtual void visit(Member2 const&);

private:
  size_t _count;
};

// CountVisitor.cpp
#include <CountVisitor.hpp>
//#include <Member1.hpp> // where you would include, but unnecessary here

void CountVisitor::visit(Member1&) { ++_count; }
void CountVisitor::visit(Member1 const&) { ++_count; }

void CountVisitor::visit(Member2&) { ++_count; }
void CountVisitor::visit(Member2 const&) { ++_count; }

And you use it as:

// main.cpp
#include <iostream>

#include <Container.hpp>
#include <CountVisitor.hpp>

int main() {
  Container const c = /* something */;

  CountVisitor cv;
  c.accept(cv);

  std::cout << cv.count() << " items in the container\n";
}

The weakness of this design is that a new visit method need be implemented for each new class directly deriving from MemberBase, and thus the MemberBase hierarchy is not so open. This can be alleviated using the Acyclic Visitor; however, I have rarely needed it.

To “extend” the ability, you can have Visitor::visit and MemberBase::accept return an “action” to be executed (erase, clone, etc…) and deal with this in the two loops you actually have. It could be reduced to one loop using some tricks…