"Dave" <be***********@ yahoo.com> wrote
Hello all,
The methodology of policy-based design states that one should inherit from
policy classes and, of course, these classes must provide an agreed-upon
public interface and semantics.
I would like to understand better why inheritance, rather than containment,
is espoused. The only things I can see that inheritance provides beyond
containment is the possibility of polymorphism and access to protected
members. Since neither of these are needed when trying to gain access to
the functionality of a policy class, why is inheritance espoused over
containment?
There are a few minor reasons. The first is space efficiency. Consider the
following examples:
template <typename T>
class ByInheritance : public Policy1<T>, public Policy2<T>
{
// ...
}
and
template <typename T>
class ByComposition
{
Policy1<T> p1;
Policy2<T> p2;
// ...
}
If 'Policy1' and 'Policy2' contain only code, they're basically empty and the
compiler may (and probably will) fold them into 'ByInheritance' such that they
will take no additional space. If 'ByInheritance' had no data members of its
own, its size could conceivably be as small as 1 byte.
By contrast, the class 'ByComposition' , because it contains explicit instances
of 'Policy1' and 'Policy2', will be bigger by no less than 2 bytes. This is
because the instances of 'Policy1' and 'Policy2' must be given unique
identities and therefore unique memory addresses.
A second reason for using inheritance over composition is to simplify the code.
If you want to expose a function 'xyz()' that is defined by one of the
policies, inheritance does so implicitly. Using composition, you would have to
forward the call to the underlying object.
Those are the two most basic reasons.
When you use containment -- which is not the same thing as composition --
you're moving into the realm of aspect-oriented programming in which the
policies can be changed at runtime. It's more versatile, but also much less
efficient.
Claudio Puviani
