Dependency injection + full virtual vs interfaces

Question

I quite often find myself creating interfaces that I am using just at the signature to inject a dependency, ending up with class AIface and class AImpl : public AIface. And quite often I never implement any other subclass of class AIface

Is there any advantage of this approach vs using directly the implementation with all public method virtual?

---

Longer Explanation:
Say we have a zoo with a cleaning service. We do TDD, and we want to be able to test the Zoo with a fake FeedingSvc, so we go for dependency injecton.

What is the difference between:

class FeedingSvcIface{
   virtual void performFeeding() = 0;
} ;
class RoboticFeedingSvc: public FeedingSvcIface{
           void performFeeding();
};
Class Zoo{
   Zoo(FeedingSvcIface&);
//...
};

vs

class RoboticFeedingSvc{
    virtual void performFeeding();
};
Class Zoo{
   Zoo(RoboticFeedingSvc&);
//...
};

(And if ever needed, extract the interface in the future)

In terms of testing, the former seems easier.

I usually find natural to add interfaces when there is a I speak to a class that "crosses layers" but some times it is just about testing.
I know that in the future I might have to implement other types of FeedingSvcs but why doing the abstraction today if I don't really needed?,
I might split two classes just to encapsulate some logic.

Answer 1

The advantage of sticking to best practices, design patterns or other idioms is that although you make a bit of extra effort now, you gain more in the long run.

Imagine the scenario where you work in a team, with multiple developers, some experienced, some not.

You are the creator of the Zoo mechanism, but you decide, that for the time being, you will implement the Zoo on a KISS principle without adding the extra abstraction . You set yourself a mental note (or a even a nice little comment) stating that "If there shall be multiple distinct behaviors of the RoboticFeedingSvc there shall be Abstraction over the dependency injection !".

Now , because of your really awesome work, you get to go on a vacation and some junior developer will remain to mantain your code.

One of the tasks of the developer will be to introduce a ManualFeeding option and a hybrid option. How many ways to do this can you think about (with disregards to any coding principle) ?

Because you, the creator, didn't enforce the way the mechanism grows, the junior developer will look at your comment, add a "LoL u mad bro :) " comment , and then choose one of the following :

• Create a base interface to be derived by other FeedingSvcs (you got lucky here)
• Create a dependency injection to the RobotFeedingSvc using a strategy pattern (have some functors to be set in terms of how to feed something)
• Make RobotFeedingSvc a composite between Feeder, Feeded, and some Action function
• Make the RobotFeedingSvc a singleton factory (because singletons factories are awesome and fancy ) that somehow is used inside the Zoo to return the apropriate feeding technique (important thing here is that he used singleton and factory)
• Create a templated version of the Zoo that takes a templated version of RobotFeedingSvc that is partially sepecialized according to given FeedingPolicy and Feeder (because he just bumped into templates, and templates should be used everywhere).

I guess we could sum up the story in fewers lines :

Making the initial effort to properly make the abstractions layer required in your application to make it scalable in terms of functionality will help other developers (including here future you ) to quickly understand the proper way to implement new features using the existing code instead of just hacking through it with some wild ideas.

Forcing your Zoo Class to take an interface instead of a concrete class is pretty much equivalent to leave a comment saying that new functionalities need to implement this interface.

Allowing a concrete class to be passed as parameter might switch focus on how to change the concrete class rather then implement something on top of it.

Another more technical reason would be the following :

He needs to add new functionality , but he's not allowed to change the Zoo implementation. What now ?