Re: Warning
On 5 Mar, 09:26, Michael Doubez <michael.dou...@free.fr> wrote:
On 4 mar, 19:37, James Kanze <james.ka...@gmail.com> wrote:
On Mar 4, 8:32 am, Michael Doubez <michael.dou...@free.fr> wrote:
On 3 mar, 21:10, "Alf P. Steinbach" <al...@start.no> wrote:
* Leigh Johnston:
IMHO "don't derive from concrete class" is a poor wording.
I prefer "inherit an interface, not an implementation"
(IIRC adapted from Gamma&GoF).
IMNSHO inheriting from a concrete class is perfectly valid
when you only want to add to the interface of an object -
after all, it is part of the 3 fundamental OOP rules.
Before arguing against the rule, it would be interesting to
see who is proposing it, and why.
I cannot remember who stated them, it dates to my academics:
"A computer language is object-oriented if they support the
three fundamental features: polymorphism, inheritance, and
encapsulation."
Which doesn't really address the question: C++ does support
those three fundamental features, so it is object-oriented.
(But it's not only object-oriented; it supports other things as
well.) And those three features say nothing about deriving from
a concrete class---the template method pattern was frequent long
before the GoF named it; as far as I know, it was always
considered good OO practice. And if the base class in the
template method pattern provides a default implementation, it is
concrete.
Inheritance in the OOP sense, i.e. (arguably) to reuse a class
implementation in order to *add* to its interface (not
modifying its internals, that's polymorphism).
To date, the only thing I've seen recently is a mention that
Herb Sutter cites it. Until I've seen why it's being
recommended, I can't really argue one way or the other. (I
haven't actuall seen anyone propose it since about 1995, but
I haven't seen everything. Still, I would like to know what
is wrong with something like:
class TemplateBase
{
private:
virtual void customizationFunction();
// with a default implemenation
};
A class using the template method pattern for customization,
but which provides defaults for all of the customization,
seems like a classical example of a case where a concrete
class is actuall designed to be used as a base class (with
public inheritance).
IMHO, part of the misunderstanding stems from the fact that in
C++, polymorphism is /usually/ performed through inheritance.
As it is in many modern OO languages. Static typing isn't
without advantages.
As a consequence, in C++ a class can inherit from another for
both reasons: reusing code (of the base classe) and create a
polymorphic implementation.
Whether it is a good thing or not is IMO what is (should be)
debated here; should a virtual function from a base class be
implemented ? Separating the concern, with your example we
could write:
class TemplateBaseIsPolymorphic
{
private:
virtual void customizationFunction()=0;
};
class TemplateBase: TemplateBaseIsPolymorphic
{
private:
virtual void customizationFunction()
{
// default implementation
}
};
From the C++ language point of view, this doesn't add a lot
and personally I prefer the original example.
Yes. Separation of concerns is a good principle, but there are
times that it can be taken too far. (Actually, which of the
above is preferrable depends on the context. What if it were:
class TemplateBase
{
virtual void customizationFunction() = 0;
};
class DefaultTemplate : public TemplateBase
{
virtual void customizationFunction()
{
// default implementation...
}
};
..)
Deriving from classes which weren't designed to be bases
(such as the standard containers) is generally a bad idea.
That's because, IMO the standard containers usually have a
complete interface and there is no need to.
Also, maybe. But my rule holds: deriving from a class which was
not designed to be used as a base will generally cause problems
in the long run, and should generall be avoided. (There are
exceptions, and I have no problems with people deriving in order
to provide a few special constructors; e.g. to create a fully
filled const vector.)
--
James Kanze