Dont Distinguish Between Classes And Interfaces

I've seen many people say you should have a convention for naming interfaces differently from classes. So Dictionary should be called iDictionary or DictionaryIF. The convention is used a lot by people used to COM and HungarianNotation. But I don't encourage the practice. I would tell you why but Josh explained it better, so I moved his comment over here. -- MartinFowler

I'd add however that if the convention for the framework you use, the DotNet framework for example, is to have I prefixed to all interfaces, it's probably a good idea to go with the grain and write your code the same. Though I agree in principle, in practice I want my code to look like the rest of the framework.

I used to place an "I" at the end of the names of my interfaces. But as I continue to learn more about the rhythm of refactoring, I'm starting to see the wisdom in making class and interface names look the same. Here's why: during development you know that you could use an interface to make something really flexible (vary the implementation) but there may be no real need to vary the implementation today. So instead of "OverDesigning" by anticipating too much, you stay simple and make the thing a class. (In other words, use ExtremeProgramming to DoTheSimplestThingThatCouldPossiblyWork, because YouArentGonnaNeedIt right now.). And somewhere you write a method signature that expects an object of that class type. Then, a few days, weeks, months later, there is a definite "need" for the interface. So you convert the original class into an interface, create an implementation class (that implements the new interface) and let your original signature (or signatures) remain unchanged. -- JoshuaKerievsky

I interpret YouArentGonnaNeedIt and DoTheSimplestThingThatCouldPossiblyWork oppositely (not a word, but it should be!) in this case. I tend to WriteInterfacesBeforeClasses. -- MarkAddleman

Exactly, I think the above fails to keep in mind one of the most important design principles, "always (try to) program to an interface, never to a class. -- Jürgen Hauser

But you can program to an interface and still write a class. An interface is just a set of methods; classes have those too. Josh is suggesting that you write a class with the signature your interface expects, use only those methods (access control and SingleResponsibilityPrinciple help here), and then down the road, if you need an interface, you create one with the same signature as the class and rename the implementing class. All your existing code works fine, because the class and interface have the same signature, and you can then define new classes that implement the interface.

I've used this pattern to create MockObjects for classes that weren't designed with testability in mind. Emulate the signature, rename the original class, then test away. -- JonathanTang

This is an example of the ShieldPattern. -- AlistairCockburn

This is a strong point, but I can't help but think that it is extremely tied to ExtremeProgramming. Under less extreme conditions, I could see how someone might want to differentiate their interfaces from their classes using a scheme like InterfacesShouldBeAdjectives in order to provide a cue that something is an extension point or HotSpot. As such, I would expect interface names to be differentiated from class names more in frameworks. I haven't really looked at the JavaLanguage HotDraw yet, but I thought that I've heard that it distinguishes. Good self-documentation for a framework.

On the other hand, ExtremeProgramming is growing on me. The donkey may starve trying to decide among these two bales of hay. -- MichaelFeathers

The ExtremeProgrammingMaster eats from the simplest bale that he can possibly find.

ErichGamma and I recently wrote JTest [JavaTest] together. [Latest version is called JUnit; see JavaUnit or TestingFramework.] It is a Java transliteration of a TestingFramework I wrote for SmalltalkLanguage a few years ago. The interface is just called Test. The subclasses are TestCase and TestSuite. It is absolutely clear to both of us that this is the right naming scheme for this framework. -- KentBeck

JavaLanguage has a DesignBurp, in that when a class inherits from another class it uses "extends", but when it inherits from an interface it uses "implements". The language distinguishes between them in other ways, too. The designers apparently thought you should know what kind of thing you are dealing with. That's the thought that's echoing in these naming conventions. -- DaveHarris

I could argue the reverse conclusion, though. If the file uses "extends" and "implements" to distinguish the two types, why do I need to redundantly code the information into the name? The information is explicit in the file declaring the class or interface and explicit in the file using the class or interface. The name doesn't tell me anything that is not already coded into the file! -- WayneMack

Regarding MichaelFeathers' comments above: someone might want to differentiate their interfaces from their classes using a NamingConvention scheme. Is the NamingConvention really the best place to bring the distinction between interfaces and classes to the attention of the programmer? Or would it be better if the programming environment (ClassBrowser?) brought this information to light? Do any JavaIdes do this already? (This comes back to the arguments for and against HungarianNotation, of course).

VisualAgeForJava does highlight the distinction between classes and interfaces in their development environment. In any hierarchy view, a class will be prefixed by a circle with a "C" in it, while an interface will have an "I" in it. -- KyleBrown

Likewise, EclipseIde uses a green circle with a "C" for classes, a purple circle with an "I" for interfaces, and a gold circle with an "E" for enums.

By listening to other developers' discussions of interfaces with adjectives as names that one is not distinguishing between classes and interfaces, but instead one is putting an implied "Object" after the adjective. That is, in a conversation one will talk about a "Cloneable Object" not just a "Cloneable." So, I think the question comes down to "Should something like "Cloneable" be named "CloneableObject" or should we just accept that a type with an adjective name has an implied "Object" appended?"

I personally prefer not to develop by convention, so I lean toward using "CloneableObject" as the name of the interface.

-- HankRoark

Notice, that in everyday English, '*able' words can be used as nouns (e.g., 'an unmentionable'); technically, any noun name could also be appended with 'object'.

The use of adjectives are useful sometimes, but they may not be the way to name interfaces in every case. Adjectives seem to cast the interface -- and implementing objects -- in a passive sense: "You can do this action to this object." An object that implements Cloneable is an object that can be cloned.

But there are plenty of cases where you want the implementing objects to do something much more active. Look at the Collection family of Interfaces in JavaLanguage: They're all named things like List, Set, SortedSet, etc. If you were completely unfamiliar with the Collection classes, you might first try to instantiate these interfaces, but you'd learn pretty quickly.

Here's a thought. This is highly dependent on the Domain being the source of your key abstractions. Instead of naming the interfaces something special, name the interfaces to match the abstraction and suffix the implementing classes with Impl. Example: You have a WidgetFactory abstraction (AbstractFactory pattern), you name the interface WidgetFactory and the classes MotifWidgetFactoryImpl and WindozeWidgetFactoryImpl. FYI in JBuilder the project window doesn't differentiate between classes and interfaces but does in the structure window. -- StevenNewton

Been through this argument in the Forte environment at a previous company, not JavaLanguage, and fun to see the same debate here. In the above example, the need to distinguish really doesn't exist. You can have the interface as WidgetFactory and the two implementations as MotifWidgetFactory and WindozeWidgetFactory. Where we ran into the naming convention debate was when you have a single implementation of an interface, and in that case we settled more or less on this convention - giving the interface the simple, easily remembered name and suffixing the implementor. However, in the light of ExtremeProgramming, I see that building an interface where there is only currently a single implementation gets into the YAGNI deal. Yippie Kai Yay. -- JimWeaver

The reason that JBuilder doesn't differentiate between classes and interfaces in the project window is because it's showing neither classes nor interfaces there, it's showing files. This is, clearly, a big difference, especially since you can have more than one class per file. -- Addaon

I think a naming convention, if any, should be based on use rather than interface or class. Cloneable and Serializable are indeed interfaces, but more so, they are marker interfaces that can be mixed and matched together. Something like Test in JavaUnit is being used more as a base protocol or base class, so it makes sense for it to be simply named Test. Just my two cents... -- RobertDiFalco

So the distinction is not 'class' vs 'object' as such, but 'construct that describe a thing' vs 'construct that describes a behaviour'. I like it. In the CommonLispObjectSystem we call the latter `MixIns'. Whether they have implementation or not is a side issue; whether they're supposed to live on their own is the deciding factor. See Marty Hall's explanation at http://www.apl.jhu.edu/~hall/java/mixins.text -- DanBarlow

Wow, it's been a while since this was edited.

The java.* hierarchy already has a few patterns for this, mostly from the collections and JavaSwing classes. I'll use "Something" as an example of the pattern.

Something - an interface that everyone should use as parameters and return types.

AbstractSomething - a partial implementation that has lots of functionality, and the end-user just has to fill in the blanks.

DefaultSomething - a reasonable basic implementation. Usually extends AbstractSomething if it exists, else implements Something. I like to use "GenericSomething" as the name for this (or something very close). A GenericSomething can be instantiated (and this makes it different from an AbstractSomething), and most often is specialized for individual situations. -- TomStambaugh

An interesting variant on this is for JavaBean listeners with the AdapterPattern, but that is a bit OffTopic. -- ChrisDailey? 2002-02-12

Hmm - I don't think this is off topic at all. The classes in question are implementations of interfaces, and it could be argued that instead of DefaultSomething we should use SomethingAdapter, because the class is a kind of 'identity' adapter.

This is more off topic - what about preserving some kind of use (alphabetical) ordering in IDEs? Using AbstractSomething etc. will mean that all the Abstracts will be grouped together rather than the Something-related code. Is this desirable?

-- DannyAyers

Instead of the prefixes used by the standard libraries, adding suffixes ensures that abstract types and implementations appear together in listings and documentation. Using the Something example,

   //package-private base class for variants 
   //returned by factory class
   class _SomethingWorks{...}

   //base of public implementation hierarchy
   abstract public class _SomethingCore extends _SomethingWorks{...}

   //factory class
   final public class _Somethings{...
     public static _Something newOld(){...}
     public static _Something newNew(){...}
     public static _Something newBlue(){...}
   ...}

-- DavidWright

IMHO, the reason you shouldn't distinguish between classes and interfaces is that the only time your code cares is when you instantiate new objects. If you distinguish between the two in the naming of the objects, odds are you distinguish between the two when you think about them. The differences between classes and interfaces matter syntactically in the class definition (a convenience to aid the compiler implementors), and semantically only in that you can instantiate (some) classes.

You are wrong. In single inheritance languages like CeeSharp and JavaLanguage, you need to distinguish them. You can't just willy-nilly decide to change an interface to a class; it'll break any existing class that already inherits from a different base class, but implements that interface. Every concrete class implementing an interface very much cares whether it's a class, or an interface; that semantic difference, matters a lot.

Once an object is instantiated, the only thing that you care about after that, from the point of view of client code, is the object's type. In particular, you only care about the type you wish to use. Every user-defined class in JavaLanguage has at least two types, both of which are classes. Many classes have several types. As a developer, you should chose the one that is most appropriate, and not focus on the one that happens to correspond to the underlying object's class.

Instead of using the NameSpace to differentiate between classes and interfaces, use it to highlight factories, and move the creation logic to those factories. Then, you can free your mind from these petty differences and focus on what's important.

As an aside, the argument put forward above that you should be able to easily determine what are classes and what are interfaces so you know which to extend and which to implement is a bit spurious. If you don't know enough about a type to determine if you extend it or implement it, you have no business doing either. :) In any case, the generated JavaDoc will sort out the differences for you.

-- RobertWatkins

Correct. IDEs give the option to extend classes but to implement interfaces. If you (like me) don't use an IDE, then use the JavaDoc and your own knowledge. If all else fails the compiler will tell you, or you'll get a RuntimeException in your UnitTests if you are instantiating dynamically. You should know the API well enough before you instantiate, and in any event you will find out within a few minutes at most. The most important thing is to communicate your intentions clearly in your code; call WidgetFactory.configure(properties) to configure a factory from properties, or WidgetFactory.getComboBox() - generic actions that apply to all widget factories - but MotifWidgetFactory.getAMotifOnlyWidget() to get a widget that only exists for Motif and show other developers that this is exceptional code.

-- WillChamberlain

In Java, I usually prefix my interface names with an 'I', because I've found that I commonly need both an interface and a class, which it would be convenient to name the same thing. When creating some API, I need the class to provide default behaviour for the API, and the interface to make sure other people can implement it even if they need to use something else as a base class. So I might have an IMonitorExtension interface and a default implementation of it called MonitorExtension. Of course other conventions are possible (AbstractMonitorExtension, BaseMonitorExtension, etc).

CategoryJava CategoryInterface