ILikeIt. If you need to add functionality in an abstract class, have your absract class implement the interface.

Martin makes the assumption that you own all the code that implements the interface. If you don’t, then changing to an abstract base class is not a good thing at all.

By exposing an “IWhatever” interface that I can implement against, you’re setting up a contract with me that makes certain guarantees…

I know it’s just an interface, so deriving from it is not going to do anything unexpected beyond requiring me to implement those methods (and any code that will be called is my own). Since I know it’s an interface, I can choose to derive from a different abstract base class without fear of this causing me any problems.

Now you may still decide that IWhatever was a big mistake in your next release, so you may deprecate or remove it and provide an alternative “AbstractWhatever” class. I know by the semantics of it what I need to change to make this all work again, and I’m okay with that.

Now this isn’t as important with private interfaces that are only being used with your code (and will only ever be used with your code)…but now you’ve got some inconsistency in how your interfaces are handled, and if you ever *do* need to expose one of those internal ones, you’ll regret not having named it IWhatever from the get-go.

So…three rules:

1. Don’t screw with a public contract. If you must, remove it and provide the new contract.

2. Prefix your interfaces with an “I”. ILikeItToo.

3. Name your abstract classes AbstractWhatever… unless you plan on your abstract classes morphing into concrete implementations. (I assume this is where you might want to argue with me the most…) :)

All that being said, I’ve asked myself these same questions and gone back and forth, so please try and convince me otherwise…

I agree that we should not change public contracts, but I strongly disagree with naming abstract classes with an Abstract prefix or suffix. This notion of naming classes with Abstract, Concrete, and Factory prefixes or suffixes reminds me too much of using Hungarian notation to work around deficiencies in loosely typed languages. These types of details belong in the XML documentation and in the help files.

I knew I’d get arguments here… :)

I guess you’re assuming that abstraction is not a contract. When I provide an AbstractWhatever class, I’m making a contract that this class will *never* be a concrete class. I have no intention of ever directly instantiating one of these things, and I’m providing it to support whatever is deriving from it. The name enforces the notion that you shouldn’t be changing the class from abstract… consider deriving your own concrete class from it, instead. It fosters a realization in others that may be working with the code that changing this thing is going to affect more than just itself.

If, in the course of refactoring, you discover that you actually *do* need a concrete instance of this thing you thought was abstract only, then derive from the abstract and start pushing all the logic up into the new concrete Whatever class until you can finally get rid of your AbstractWhatever class.