Inheritance

[Dart]

What are the major advantages of inheritance of a class of no virtual
functions, promoting code re-use? Thanks!

 

[Phlip]

What are the major advantages of inheritance of a class of no virtual
functions, promoting code re-use? Thanks!

Call that a "convenience class", and only do it when the derived class is
very small.

Do _not_ do it so that "B can do the same things as A, and more".

Here's an example:

typedef std::auto_ptr<Field> FieldPtr_t;

FieldPtr_t static
fields[] = {
FieldPtr_t(new Field( "first_name" , IDC_EDIT_FIRST_NAME )),
FieldPtr_t(new Field( "last_name" , IDC_EDIT_LAST_NAME )),
FieldPtr_t(new Field( "address_1" , IDC_EDIT_ADDRESS_1 )),
FieldPtr_t(new Field( "address_2" , IDC_EDIT_ADDRESS_2 )),
FieldPtr_t(new Field( "city" , IDC_EDIT_CITY )),
FieldPtr_t(new Field( "state" , IDC_EDIT_STATE )),
FieldPtr_t(new Field( "zip" , IDC_EDIT_ZIP )),
};

That looks heinous, but we must do it because auto_ptr's constructor is
explicit. Defeating this feature makes the code cleaner, entirely as a
convenience:

FieldPtr_t: std::auto_ptr<Field>
{
FieldPtr_t(Field *p):
std::auto_ptr<Field>(p) {}

};

FieldPtr_t
fields[] = {
new Field( "first_name" , IDC_EDIT_FIRST_NAME ),
new Field( "last_name" , IDC_EDIT_LAST_NAME ),
new Field( "address_1" , IDC_EDIT_ADDRESS_1 ),
new Field( "address_2" , IDC_EDIT_ADDRESS_2 ),
new Field( "city" , IDC_EDIT_CITY ),
new ComboField( "state" , IDC_COMBO_STATE ),
new Field( "zip" , IDC_EDIT_ZIP ),
};

Per the /Effective C++/ books, one should only inherit if one then overrides
a virtual method. Ultimately, the best way to share implementation is
delegation, not inheritance. Use that to permit the Liskov Substitution
Principle.

 

[Claudio Puviani]

What are the major advantages of inheritance of a class of no virtual
functions, promoting code re-use? Thanks!

A typical proper use is to implement policy-based templates, as described in
"Modern C++ Design" by Alexandrescu or "C++ Templates" by Vandervoorde &
Josuttis. I won't rehash the contents of these two excellent books, but you can
think of it as using inheritance to assemble building blocks into a final
template instantiation. The advantages? Performance, especially when combined
with inlining. Added flexibility, albeit at the cost of complexity.
Non-intrusive extensibility. It may not be a magic bullet, but it can sure do
some nice card tricks.

A more questionable use is representing "implemented-in-term-of" relationships
(IOW, sharing implementations). Still more questionable is using it as a
mechanism to add methods to a third party C struct. Most questionable of all,
in my opinion, is creating custom types from existing classes that were never
meant to be derived from, such as the standard containers or strings.

Claudio Puviani

 

[jeffc]

Per the /Effective C++/ books, one should only inherit if one then overrides
a virtual method. Ultimately, the best way to share implementation is
delegation, not inheritance. Use that to permit the Liskov Substitution
Principle.

It's very possible, and valid, to have a design with inheritance where the
base class has no virtual functions, yet the Liskov Substitution Principle
still holds.

 

[Claudio Puviani]

It's very possible, and valid, to have a design with inheritance where the
base class has no virtual functions, yet the Liskov Substitution Principle
still holds.

It's possible in controlled circumstances, but it's extremely contrived. The
derived class cannot override any functions of the base class without violating
the LSP, except in template instantiations. The poor programmer who has to
inherit from such a base class is limited to adding new functions. All in all,
it has all the earmarks of a bad design decision.

Claudio Puviani

 

[jeffc]

It's possible in controlled circumstances, but it's extremely contrived.

I disagree - it's not necessarily contrived. If the model calls for
additions in behavior, but not alterations to existing behavior, then so be
it. It's not a question of control, it's a question of modeling and design.