Abstract vs Interface

Whatever your language of choice, at some point you're going to need to think about inheritance, composition, and hierarchy. That's when you start thinking about abstract classes vs interface classes. Regardless of what your language calls them, pretty much all modern languages (C++, Golang, Javascript. Python, etc) include the functionality directly or indirectly.

The difference between the two is kind of subtle, but for the sake of simplicity let's say an interface is the definition of the contract between caller and provider, but has no implementation, while an abstract class provides at least one overrideable concrete implementation of part of that contract. In neither case can you use them without providing your own implementation. In both cases though, you can just act against the contract and not care about the implementation.

The place where it gets interesting is when you start talking about composition vs inheritance, IsA vs HasA, and the future. Generally speaking, you can inherit (IsA) one thing, but you can implement (HasA) many. So what happens when you want to add some new functionality or capabilities? What if you only want to add it to some things and not others?

A great example is Compareable. You could put it on the most basic element in your hierarchy. You'd have to give it a default implementation that failed with NotImplemented or everything would have to provide its own implementation that did that, but that would break the DRY rule. Then you'd have to implement it on everything that wanted to be Compareable. That's basically the same amount of work so no loss there. What would be a loss though is that now your compiler can't know if Compare actually works or just fails, so you're forced to try it out, hope it works, and then deal with the fallout. On the other hand, you could make Compareable an interface, define it rigorously, and then add it to the things that you plan on making comparable. Then when some developer writes instanceofthing.Compare(otherinstance) you get a warning up front that the capability doesn't exist. At that point the developer can implement it or do something else. And if you inherit from something that implements an interface you get that as well.

So, is an SDV a Car, which is a MotorizedVehicle, which is a Transport, or is an SDV a thing which implements the interfaces of a MovingPlatform, SensorPackage, and DecisionMaker? Discuss in the thread.