Question

I wrote this yesterday, in a class Foo inheriting from Bar:

public override void AddItem(double a, int b) {     //Code smell?     throw new NotImplementedException('This method not usable for Foo items'); } 

Wondered subsequently if this is a possible indication that I should be using a Bar, rather than inheriting from it.

What other ‘code smells’ could help to chose between inheritance and composition?

EDIT I should add that this is a snippet, there are other methods which are in common, I just didn’t want to go into too much detail. I have to analyse the implications of switching to composition, and wondered if there might be other ‘code smells’ which could help to tip the balance.

Answer 1

The example you gave above is clearly a code smell. The AddItem method is a behaviour of the base class Bar. If Foo doesn’t support the AddItem behaviour, it shouldn’t inherit from Bar.

Let’s think of a more realistic (C++) example. Let’s say you had the following class:

class Animal {     void Breathe() const=0; }  class Dog : public Animal {     // Code smell     void Breathe() { throw new NotSupportedException(); } } 

The base abstract class Animal provides a pure virtual Breathe() method, because an animal must breathe to survive. If it doesn’t breathe, then by definition it is not an animal.

By creating a new class Dog which inherits from Animal but doesn’t support the Breathe() behaviour, you are breaking the contract stipulated by the Animal class. The poor dog won’t survive!

The simple rule for public inheritance is that you should only do it if the derived class object truly ‘is a’ base class object.

In your particular example:

• Foo doesn’t support the AddItem() behaviour stipulated by the Bar contract.
• Therefore, by definition, Foo is ‘not a’ Bar, and shouldn’t inherit from it.