Accessing information about derived class from abstract base class in C++ - c++

Question

So I'm trying to move some common code in a few classes that implement an interface* to an abstract base class. However, the abstract base class needs to know a little bit about how the derived classes want to do things in order to determine exactly what to do. However, I'm not entirely sure if I should implement this using a pure virtual function or a protected member variable.
I'll give a simple example describing what I'm trying to do.
The interface:
class SomeInterface
{
public:
void DoSomething() = 0;
// ...
};
The abstract base class I'm trying to implement using pure virtual function:
class AbstractBase : public SomeInterface
{
public:
virtual void DoSomething()
{
for (int i = 0; i < GetNumIterations(); i++)
{
// Call implementation in derived classes, for example
DoSomethingImpl();
}
}
protected:
virtual void DoSomethingImpl() = 0;
virtual int GetNumIterations() = 0;
};
A derived class:
class Derived1 : public AbstractBase
{
protected:
virtual void DoSomethingImpl()
{
// Do actual work.
}
virtual int GetNumIterations()
{
return 5;
}
};
Another derived class:
class Derived2 : public AbstractBase
{
protected:
virtual void DoSomethingImpl()
{
// Do actual work.
}
virtual int GetNumIterations()
{
return 1;
}
};
Or the other way would be using a protected variable:
class AbstractBase
{
public:
virtual void DoSomething()
{
for (int i = 0; i < numIterations; i++)
{
// Call implementation in derived classes, for example
DoSomethingImpl();
}
}
protected:
virtual void DoSomethingImpl() = 0;
int numIterations;
};
And the derived would be like:
class Derived1 : public AbstractBase
{
public:
Derived1()
: numIterations(5)
{
}
protected:
virtual void DoSomethingImpl()
{
// Do actual work.
}
};
Same thing for Derived2.
I know there's some overhead related to virtual methods (probably insignificant, but still), and that the protected variable might not be great for encapsulation, or that it could be forgotten and left uninitialized. So my question is basically, which of these is preferrable and why, or should I avoid this scenario altogether and try to handle it differently?
Note: my actual code is a bit more complicated. I havent't actually tested to see if this code works, so forgive me if it's incorrect.
*When I say interface, I mean a class containing only pure virtual functions.

Answer 1

In fact, what you are trying to do is very common. However, there is one more approach to implement this which explicitly defines the contract for derivatives of AbstractBase. Modifying your example it would look as follows:
class AbstractBase : public SomeInterface
{
public:
explicit AbstractBase(int numIterations) : numIterations(numIterations) {}
virtual void DoSomething()
{
for (int i = 0; i < numIterations; i++)
{
// Call implementation in derived classes, for example
DoSomethingImpl();
}
}
protected:
virtual void DoSomethingImpl() = 0;
// Can omit it, if not needed by derivatives
int GetNumIterations() { return numIterations; }
private:
int numIterations;
};
class Derived1 : public AbstractBase
{
public:
Derived1() : AbstractBase(5) {}
protected:
virtual void DoSomethingImpl()
{
// Do actual work.
}
};
class Derived2 : public AbstractBase
{
public:
Derived2() : AbstractBase(1) {}
protected:
virtual void DoSomethingImpl()
{
// Do actual work.
}
};
As you probably understand now, by contract I meant the constructor which now explicitly forces derivatives of AbstractBase to initialize it properly, so you would never mess it. The downside of this approach is that it introduces the additional field which would be possibly duplicated among numerous copies of say Derived1 in case if this 5 never changes in your situation. So if you care about memory footprint, then I'd not go for this one. However, if numIterations can be changed, then this approach is certainly the best of the 3 proposed ones. All you'd have to do is add proper setters for it into AbstractBase.
NOTE: My approach is sort of safer and better alternative to your 2nd one as it exactly addresses the issues you've mentioned, namely encapsulation hole (redundant exposure of implementation details) and contract weakness (when you might forget to initialize numIterations because you are not forced to). Therefore, you do not want to use your 2nd approach in your current situation.
The first approach that you've proposed is good too. Its advantage over mine is that it does not introduce any memory overhead. And as long as "number of iterations" does not change you don't need to introduce a field to store it. As a result, you have to override this GetNumIterations method in every derivative, but it's OK since this is a part of (strong) contract (pure virtual method) and you can never mess it too.
To conclude, as you can see, these 2 approaches are mutually exclusive, and it is very easy to decide which one to use by simply applying their pros and cons to your particular situation.