I very much agree that the fundamental problem seems to be that those who think prefixing interfaces with “I” have probably misunderstood their use. Perhaps a related problem is that most programmers have yet to grasp dependency injection too? They live in a world where you create new instances of classes willy-nilly, and in that context it feels wrong (to them) to let interfaces be first-class participants. When you move to dependency injection you notice that most of the things you interact with are actually interface types, and the “I” sticks out like a sore thumb.

Thank you for taking your time, your examples are great and show the issue from a more concrete perspective.

a HibernateUserDao extends AbstractHibernateCrudDao and implement UserDao and will be referred to as a UserDao absolutely everywhere in my code except for where the dependency injection is configured to instantiate a concrete instance.

With IoC, the contract becomes the first class type which all of your other code interacts with, so singling it out as ’special’ via the ‘I’ prefix is pretty much exactly the opposite of intent. If anything, the ‘Hibernate’ and ‘AbstractHibernate’ are the equivalent of the ‘I’ prefix on an interface, but are much more appropriate, marking particular implementations that are mostly beneath the radar of a developer that is merely using the api, since that dev will only interact with the contract. The dev that maintains the API must know about the concrete implementations, but the maintaining dev necessarily must know the details of the api internals, so it makes sense for that dev to utilize what are, effectively, private prefixes in order to label classes.

Going down one layer and looking at the domain model itself makes this even more apparent. Let’s say that for testing’s sake, my domain model is implemented as a set of interfaces with a concrete implementation that is probably (in java, anyway) annotated with information about the storage mapping of the class in question. So I can have a Car which has a Wheel and a Tire, and all of my business logic will interact with Car, Wheel, and Tire objects, or I can have an ICar, and IWheel, and an ITire and have those names scattered throughout my codebase. Since the fact that my app uses a HibernateDao is completely irrelevant to every other layer in my app courtesy of dependency injection, the fact that I am currently passing around hibernate-specific versions of the domain objects which were acquired via that same DAO is also irrelevant. I only care that it adheres to the Car, Wheel, or Tire contract.

So far as I can tell, the only people who still argue that interfaces need prefixes because they are not first-class types are those who either do not yet understand how programming to interfaces is absolutely vital to de-coupling code, or don’t yet understand just how well a framework like Spring can truly isolate each layer of an app from every other so that absolutely no knowledge of the implementation details of one layer is ever visible to any other layer. My application layers never know ANYTHING other than the interfaces that describe the layers they interact with. If I have a cross-cutting concern which demands knowledge of implementation details, then I’ll implement it as an AOP aspect that is injected between layers by the framework without the knowledge of any other involved layer, and again, only the IoC framework will need to know the specifics of the aspect’s implementation, which must necessarily match the implementation details of the layers with which it interacts.

What do you think is the purpose of abstraction, access permissions [...]

Do you prefix your public methods with “p”? If not, why not?

I for Interface C for Class S for Struct A for Abstract

There you go, lol. Joking. You know a good IDE solves all these naming convention problems. Such as Visual Studio, and yet Microsoft’s XNA prefixes I for interfaces.

Anyway, use I for interface if you distribute your code. You’re just kidding yourself if you don’t. You don’t have to use C for class, because class is the default nowadays (used to be S for struct back in the day).

I wanted to add that there is also one practical argument for not prefixing your interfaces: if you want to refactor and replace a class with a number of classes, perhaps a whole hierarchy of classes, one way is to extract an interface from the first class and let all the new classes implement that interface (another way is of course to let the new classes inherit from the original class, but mindless subclassing will come back and bite you).

If the interface has the same name as the class, no code that previously used the class needs to change. If you insist on prefixing your interfaces with “I”, all the code that just use the class need to change. It doesn’t have to change much, just an “I” needs to be added, but it has to be done.

Let’s illustrate this with an example: say you have a class called Service. So far your application has only needed one kind of Service, but now the requirements have changed and you need to introduce a number of new service types. From the perspective of the code that uses the service it doesn’t matter what kind of service it is as long as it works the way it does now. You extract an interface from the Service class, rename the class to something else and make it implement the new Service interface. Then you create the other service classes, making them all implement the Service interface. The last thing you need to change is the code that instantiates the service, making sure that it instantiates the right kind of service in the right circumstances (this part could probably benefit from being refactored into a factory). If the new interface has the same name as the old class you’re done. If not, you have a couple of fun hours wading through the rest of the code searching and replacing.

No, I don’t dislike the convention of using “able” for types, I think it’s good. My point is that the name of a type should describe it. Something serializable should be called “Serializable” if it is something serializable or “Command” if it is a command, not “ISerializable” or “ICommand”, because it is not a “i-serializable” or a “i-command”.

When it comes to abstract classes there are two variants: those that provide a basic implementation of an interface, and those that both define the interface and provide a basic implementation of it. In ActionScript and Flex an example of the first type is UIComponent (which is an abstract implementation of IUIComponent) and an example of the second is DisplayObject. In my view something like UIComponent should be called AbstractUIComponent, but something like DisplayObject should be called exactly that (however, legitimate examples of the second variant is quite rare, the first variant is almost always the right way to solve a problem). I will not say more about the second variant, and the rest of this discussion is only about the first.

Why do I think that the “Abstract” prefix is a good idea when “I” for interfaces is not? The reason is that you should always type your objects as the most abstract type possible, which means that for objects that are instances of a class descendant from an abstract class the interface type that that abstract class implements is the most abstract type, never the abstract class type. Prefixing the names of abstract classes with “Abstract” both makes it obvious that the class is abstract (which is hard in languages lacking the abstract keyword), and sets the type apart, making it obvious that it is a special type of type, one that you should think twice about when you use it. This is the same argument that most people use when arguing for prefixing interfaces with “I”, but here I think it is valid. Interface types should not be set apart, because they are not special, abstract types are, because they are only convenience classes and should never be seen (except, obviously, when they are used as parent classes).

I hope that the different meanings of the word “abstract” weren’t too confusing in that last paragraph, it really would have benefited from a diagram. A type can be more or less abstract (meaning, more or less, that it is more or less general), but a class can also be an “abstract class” (which just means that the class provides an abstract, as in not-finished, implementation of something).

You also mention that interfaces “cannot dictate which properties to make publicly accessible”, this isn’t strictly true, in ActionScript and C#, the two languages that I know of that have implicit getters and setters (a.k.a. properties), interfaces can define properties. However, that doesn’t mean that it is necessarily a good idea. It all depends on how you use the feature. It’s always a bad idea to break encapsulation, and defining interfaces that dictate how an implementing class should define its inner workings (e.g. instance variables and such) is not a desirable feature.

I’m not sure if this discussion persuades you further, but I hope that it does. Thanks for your comment.