Reusing Methods – Base Class vs Interface Rule of Thumb

inheritanceinterfacesobject-oriented

A colleague of mine came up with a rule-of-thumb for choosing between creating a base class or an interface.

He says:

Imagine every new method that you are about to implement. For each of them, consider this: will this method be implemented by more than one class in exactly this form, without any change? If the answer is "yes", create a base class. In every other situation, create an interface.

For example:

Consider the classes cat and dog, which extend the class mammal and have a single method pet(). We then add the class alligator, which doesn't extend anything and has a single method slither().

Now, we want to add an eat() method to all of them.

If the implementation of eat() method will be exactly the same for cat, dog and alligator, we should create a base class (let's say, animal), which implements this method.

However, if it's implementation in alligator differs in the slightest way, we should create an IEat interface and make mammal and alligator implement it.

He insists that this method covers all cases, but it seems like over-simplification to me.

Is it worth following this rule-of-thumb?

Best Answer

I don't think that this is a good rule of thumb. If you are concerned about code reuse, you can implement a PetEatingBehavior which role is to define the eating functions for cats and dogs. Then you can have IEat and code reuse together.

These days I see less and less reasons to use inheritance. One big advantage is the ease of use. Take a GUI framework. A popular way to design an API for this is to expose a huge base class, and document which methods the user can override. So we can ignore all the other complex things our application needs to manage, since a "default" implementation is given by the base class. But we can still customize things by reimplementing the correct method when we need to.

If you stick to interface for your api, your user has usually more work to do to make simple examples work. But API with interfaces are often less coupled and easier to maintain for the simple reason that IEat contains less information than the Mammal base class. So consumers will depend on a weaker contract, you get more refactoring opportunities, etc.

To quote Rich Hickey: Simple != Easy

Related Solutions

Object-Oriented Design – Interfaces on an Abstract Class

I'm of the belief that a class should not implement an interface unless that class can be used when an implementation of the interface is required.

BaseWorker fulfills that requirement. Just because you can't directly instantiate a BaseWorker object doesn't mean you can't have a BaseWorker pointer that fulfills the contract. Indeed, that's pretty much the whole point of abstract classes.

Also, it's difficult to tell from the simplified example you posted, but part of the problem may be that the interface and the abstract class are redundant. Unless you have other classes implementing IFooWorker that do not derive from BaseWorker, you don't need the interface at all. Interfaces are just abstract classes with some additional limitations that make multiple inheritance easier.

Again being difficult to tell from a simplified example, the use of a protected method, explicitly referring to the base from a derived class, and the lack of an unambiguous place to declare the interface implementation are warning signs that you are inappropriately using inheritance instead of composition. Without that inheritance, your whole question becomes moot.

Object-oriented – C++ Design: Functional Programming vs OOP

I think that OOP lends itself best to when you have state that you can't destroy and re-create on a whim, or where that's a bad model- for example, if you consider 3D rendering, then the state of the renderer is not trivially destroyed and recreated, and it would be suicide for your performance to do so each frame.

In C++, then you need to add the fact that it doesn't have garbage collection and many FP techniques depend upon that for remotely acceptable performance.

Otoh, from a FP POV, a Eat() function simply allows an Animal to turn Food into Poop and Energy. It's harder to imagine Eat() being anything else (for me, at least).

That's completely equivalent to the OOP variant. There's no meaningful difference between

struct Animal { ... };
std::tuple<Poop, Energy> Eat(Animal*, Food);

and

class Animal {
public:
    std::tuple<Poop, Energy> Eat(Food);
};

A functional variation would return a new Animal which has eaten.

Typically, I recursively divide my program to obtain modules/submodules/classes/functions and member functions, then I often attempt to implement those functions or member functions functionally if possible.

Best Answer

Related Solutions

Object-Oriented Design – Interfaces on an Abstract Class

Object-oriented – C++ Design: Functional Programming vs OOP

Related Topic