Benefit of class inheritance, when you could use protocol extensions?

Question

I am fascinated by the possibilities of beautiful code with protocol extensions. But I do not seem to grasp the real difference between class inheritance.

I know there are different ways to model something, like I could use composition instead of class inheritance.

But then I knew the features of class inheritance, was that the subclass could use the implementations of the superclass very easily. With protocol extensions I have this feature too, even for value types.

So the question is which features do class inheritance have, what protocol extensions do not; or when to use class inheritance instead of protocol extensions.

Answer 1

The only real benefit I found is that you can create superclass objects, which are no subclass and so you can ignore any implementation details of the subclass.

If A is the superclass of B. Then you can create A and do not have to care about anything from B.

With protocols you always have to use the adopting struct/class.

In some cases it makes sense to create a UIResponder and not a UIViewController, because you do not want that functionality and it is safer and easier to just use a class with less features.

With protocols and their extensions only, you have to choose one implementation, so to not write the same code twice there has to be multiple protocols, one for each hierarchy level of the corresponding class hierarchy.

If P2 adopts P1 and P1E is the extension to P1 and P2E is the extension of P2, then you have to create a struct/class that adopts P1 only to get a less capable version of a struct/class that adopts P2.

Answer 2

The "benefit" of class inheritance is that you can inherit stored properties and initializers which can also have a default implementation from a subclass.

But these are only minor benefits at least for me.

Answer 3

If not for Cocoa, there might not be any.

An over-simplified way to put it is "when you're working with protocols, use extensions, and when you're dealing with Objects, use subclassing".

To be less simple about it, when you're programming in Swift, you're going to have to deal with Cocoa, and when you're dealing with Cocoa, you're going to have to deal with Objects. And when you have to deal with Objects, sometimes the best way to do something will be subclassing.

Take UIViewController, with which we all must reckon. As far as I'm aware there is no UIViewControllerProtocol. That means UIViewController has lots of baked-in behavior that you can't just re-implement by declaring conformance to a protocol. If you want your app's main UIViewController to have custom functionality--which we all do--you have to subclass it. And then you get all that behavior through inheritance.

I suppose another way to put it is that class inheritance is superior to protocol extensions in those cases when you have no choice but to deal with Objects that were designed without protocols.

Which, for us Swift folks, happens often.