Question

So I’m using composition to bring together a collection of objects, all of which are derived from a base class, lets say Component. E.g:

class Component {
public:
  Component();
  ...
private:
  int m_address;
  ...
};

class SpecializedComponent: public Component {
public:
  SpecializedComponent()
  ... //and so on
};

class SpecializedComponent2: public Component {
public:
  SpecialIzedComponent2()
  ... //and so on
};

class ComponentHolder{
  SpecializedComponent* m_descriptiveName;
  SpecializedComponent2* m_descriptiveName2;
  // and so on... many different types of components
}

So, each SpecializedComponentX will communicate over a network with an individual data source, each with their own unique address. These addresses are specified in a parameter file. At the moment, I’m parsing the parameter file and the m_address is initialized in the derived class constructor – this is because each m_address is specified by the type of object we’re initializing.

Every SpecializedComponentX has some common functionality that I want to execute in the base class Component. So, I spin up a thread associated with the base class Component, right? Sure – makes sense. Until I realize that I don’t have the destination address for that component yet – because the object hasn’t been fully constructed. I want to spin up the base class thread in the ctor, but I don’t know the m_address yet.

The only way I can think of getting around this is providing a (simple) virtual function, void start(), that the derived class can call to spin up the thread once the object is fully constructed. Is this a valid and appropriate design choice or is there a pattern that I could be overlooking? Thanks.

Answer 1

Component could have a constructor with one argument that initializes m_address.