Inheritance over Interfaces?
I was looking through Microsoft's Design Guidelines for Class Library Developers, and was a bit shocked to see this advice: "Use base classes instead of interfaces whenever possible."
My experience has been that inheritance is not much fun, and interfaces are great. Anyone want to discuss?
posted by Ben Hogan at 5:08 pm
4 Comments:
There is a big difference between writing a class library and an application. In an application, the developer has full control over the code and can easily refactor implementors and users of interfaces when those interfaces change.
A class library, on the other hand, is linked into third party code that is beyond your control. Interfaces defined by a class library are both called and *implemented* by third party code. If you add a method to an interface, classes calling that interface will remain source and binary compatible with the new version. However, classes *implementing* that interface will be broken. One cannot add methods to interfaces in a class library and remain binary compatible with previous versions. If you use classes instead, you can add new methods to the base class with a default implementation and any derived classes will still work.
So, interfaces are fine in applications but cause problems in class libraries. Interfaces in class libraries need to be extremely stable to be worth using.
--Nat.
As Nat pointed out, it is good practice for class library designers to provide a base class. However, the advice is bogus.
What class library designers should do is provide (and use) interfaces, and also provide a "default" implementation which can be used as a base class, which client developers can then extend.
This gives the best of both worlds - most people can use the base class, but the interface is available for when you really need it.
Designers who only provide classes are assuming too much how their library will be used; in particular, they are assuming it will never be mocked out (e.g. for unit testing).
Robert: it's not that black and white.
By defining an interface, class library designers are assuming that the interface will never be implemented by client code, or stopping themselves from changing the interface as the class library evolves.
There's always a trade off. If the API is very stable it's worth making it an interface. If it's less stable then defining an interface brings problems down the line. Even if there's a default base class, some users *will* use the interface and that will come back to bite you later on (well bite them, and then indirectly you when you lose users).
My experience is that abstract things are usually very stable but domain-specific things are not. So it's worth defining interfaces for Predicates or Functions, since they are mathematical concepts that are not domain specific, but not worth defining interfaces for things like StockTrade or MockObject (in my case).
This doesn't apply in applications where I prefer to use interfaces as much as possible.
Also, you can create mocks from abstract classes just as well as from interfaces.
I must admit I use inheritance and concrete classes less and less every day. I would vote interfaces for almost all cases but I do see the dilemma in public APIs which are subject to extension (you cant extend an interface without breaking older users of it).
Perhaps one answer is to make the interfaces you do write, as solid and resistant to change as possible. Make the number of concrete classes as few as possible and obtainable through an interface, so it’s easier to make mock or alternate implementations.
The argument for extending classes assumes that the extra methods are optional and do not need to be known by an older implementation. It is better to get it right the first time and use an interface. Nothing you can always predict. And sometimes it's better to force upgrades.
And sometimes it's better to just enjoy a soya latte and write pointless rubbish on blogs.
Post a Comment
<< Home