Re: Static polymorphism and the LSP principle
Amanjit Gill wrote:
I am trying to do Static polymorphism with templates while mainting
the OOP philosophy (for those cases where a virtual method dispatch is
too expensive).
template<class DERIVED_>
struct IAlgorithm {
void calc() {
static_cast<DERIVED_*>(this)->calc();
};
};
struct SimpleAlg : public IAlgorithm<SimpleAlg> {
void calc() {
}
};
struct ComplexAlg : public IAlgorithm<ComplexAlg> {
void calc() {
};
};
I would like to store f.e. an vector<boost::any> list of instances of
classes that conform to the IAlgorithm interface- i.e. that contain
both SimpleAlgs and ComplexAlg - and the list should be completely
run-time alterable with regard to the order of items. Of course I
want clients only to use the IAlgorithm<> interface contract (LSP
principle).
Boost::any is dynamically polymorphic (it uses a virtual method to
confirm its stored type) - and in fact the container of algorithms as
described would require runtime polymorphism. So if the "problem" is
how to implement runtime (dynamic) polymorphic behavior using only
efficient, compile-type polymorphism - then a solution is unlikely to
be forthcoming. There is after all a tradeoff between the low-cost
efficiency of static typing versus the power (and relatively higher
price) of dynamic typing.
So the challenge here is for the program to make the right tradeoff: to
use compile time polymorphism where possible and runtime polymorphism
when needed. And certainly having a set of classes capable of both
static and dynamic polymorphic behavior would be especially helpful in
attaining this optimal balance.
I have read a paper called SCOOP ( "Static C++ Object-Oriented
Programming (SCOOP) Paradigm Mixing Benefits of Traditional OOP and
Generic Programming", by Burrus, Duret-Lutz, et all) which shows one
approach to this problem, but haven't worked through it completely.
The paper describes a clever scheme to implement compile-time
polymorphism - not run-time polymorphism. Furthermore, the paper cites
as one of SCOOP's drawbacks the fact that it produces "unusual code,
unreadable by the casual reader." So I would suggest sticking with the
current Algorithm class template (at least it's readable) - but with a
few changes: The first change I would suggest would be to remove the
algorithm types themselves from the class hierarchy. The only
requirement that this program imposes upon its algorithmic types is
that each implements a calc() method. There is no necessity that they
be otherwise related or have anything else in common. So instead of
having the algorithm type inherit from the Algorithm class template, it
would simply serve as one of the Algorithm class template's data
members:
template <class T>
struct Algorithm
{
T mImpl;
Algorithm(T impl) : mImpl(impl) {}
void Calc()
{
mImpl.Calc();
}
};
To attain the runtime polymorphic behavior that a container of diverse
algorithms would require, the Algorithm class template would inherit
from a base class, AbstractAlgorithm. AbstractAlgorithm would implement
a Non-Virtual Interface (NVI) like so:
struct AbstractAlgorithm
{
void Calc()
{
DoCalc();
}
protected:
virtual void DoCalc() = 0;
};
while DoCalc() in Algorithm would simply call its own Calc() method.
template <class T>
struct Algorithm : public AbstractAlgorithm
{
...
protected:
virtual void DoCalc()
{
Calc();
}
};
In this way, calls to Calc() are either statically dispatched for
Algorithn objects whose parameterized algorithm type is known at
compile-time - or dynamically dispatched for those Algorithm objects
whose specific algorithm can vary and therefore has to be ascertained
only at runtime.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]