An idiom that we've been convinced of lately is that when you're naming an interface, it should usually be named an adjective.

An Interface in Java describes a set of methods that a particular class may implement. It's a "type" in one respect. It's very closely related to the "Contract" notion that RebeccaWirfsBrock popularized a few years back.

An Interface or "bag of responsibility" is a way of describing that an object can do something. This seems to convince us that Interface names should be adjectives. If you think about it, a class is a noun, and an interface is a way of describing what the class does in some way. Sounds like how an adjective modifies a noun, doesn't it?

Some examples of this convention found in the Java JDK are Cloneable and Runnable. In my own programming, I had to implement a SortedVector class, much like the new ones available in the JDK 1.2. I wanted it to store arbitrary objects - but since it's sorted there must be some comparison on those objects. I did this by implementing an interface called Comparable, which implements the messages greaterThan() and lessThan(). Each implementation of this interface is different - so you have the freedom to have several ways of comparing two objects - for instance EmployeesByNameComparison and EmployeesByHireDateComparison, two concrete classes that implement the Comparable interface.

* ''Cough cough gettadatabase cough cough - top''

P.S. The original observation that some of our interface names correspond to Adjectives was made by AlistairCockburn. It's a simple realization that has profoundly changed the way I think about interfaces.

-- KyleBrown

Hmmm.. you probably implemented Comparator, not Comparable. Comparable compare an object to itself, Comparator compares two objects. Comparable is implemented on _naturally ordinable_ classes like Integer, while to sort a collection of Employees, that have no natural order, you should use a Comparator.

-- Eleusi


-----

I did a study which resulted in a paper called "Using Natural Language as a Metaphoric Base for Object-oriented Modeling and Programming" (now online: 
http://alistair.cockburn.us/crystal/articles/unlmboomp/usingnaturallanguageasametaphoricbase.html
in it I asked the question... now that we have OO, we have nouns and verbs, but where are the adjectives and adverbs?

So I asked, what is the purpose and contribution of an adjective (among other things), and came up with pretty much what Kyle said above, and hence the understanding that mixins and multiply inherited things (interfaces being prime among them) are adjectives. I find it quite natural to read of mixins or interfaces called printable / runnable / whateverable.

This is all an example of what I call ComputationalRhetoric. I just moved the next paragraph over to there.

-- AlistairCockburn

''News flash, it appears he eventually scanned it:'' "Using Natural Language as a Metaphoric Base for Object-Oriented Modeling and Programming" http://alistair.cockburn.us/crystal/articles/unlmboomp/usingnaturallanguageasametaphoricbase.html

-----

(The following is an excerpt from an email from KenAuer on naming Interfaces. He's contrasting InterfacesShouldBeAdjectives with the suggestion that Interfaces should have a suffix (like "Type") attached to the end)

As far as Interface names and types go...

I don't disagree that using adjectives for interface names leaves a bit to be desired, but I don't believe the "Type" suffix is a better solution. If you're going to use a suffix, why not "Interface"? Chance of conflict on that is probably much slimmer than with "Type". Note, however, that I'm not arguing for the "Interface" suffix. I kind of wish Interfaces had their own namespace in Java, but it's too late for that. I think we'll just have to live with inferior guidelines for naming. In general, I like using adjectives in the case of "mix-in" type interfaces (although it still doesn't always work), but not for "foundation object" type interfaces.

I'd love to hear other ideas.

-- KenAuer

----

I believe that PeterCoad uses the naming convention of starting every interface name with a capital "I" (e.g., ITheNameOfTheInterface). I don't recall if he uses the adjective style in conjunction with this - I don't think so, though. -- DavidRosenstrauch

I really like this idea of thinking of interfaces as adjectives and adverbs. But I'm no longer a big fan of distinguishing the names of interfaces from the names of classes. See DontDistinguishBetweenClassesAndInterfaces. -- JoshuaKerievsky

----
Gemstone has a convention of a suffix ("IF") on the names of interfaces. I have not reached an opinion yet. I'd almost rather have a suffix on the names of classes instead of interfaces, since interfaces should be sprinkled more throughout the code while class names should not.

A problem with using a prefix rather than a suffix is that all of the interfaces are grouped together in sorted lists.

OTOH if you have Dictionary and DictionaryIF then the interface and the most basic corresponding classes may tend to be listed together.

One more note: use of a suffix does not rule out the use of adjectives for names when that makes sense.

-- PatrickLogan

----

It is great to see this and also find a forum to talk about it. I wrote a paper exploring the interfaces as adjectives idea and examining the ramifications for component modeling. It has been accepted by JournalOfObjectOrientedProgramming. Actually wrote it to get feedback along with a refusal slip. Got accepted and no feedback. MartinFowler pointed me here (thanks!). Here are a few more thoughts.

What occurred to me was that adjectival names describe qualities and capabilities of classes. We can say that something is Elliptical (quality) or we can say that it CanSinkData (capability). The Observer pattern can be CanObserve/Observable rather than Observer/Observable. Notice that adjectival phrases can be the name of interfaces as well (CanObserve).

''How about "Observant" instead? (-:''

What I think is important about this orientation is that we do not have to be so concerned with what something is as what it can do for us, or what it means to us. We gain particularly in the area of substitutability. There are many cases where is-a doesn't quite cut it when abstracting out a base. For instance, an editor may allow the manipulation of glyphs. We know that a glyph is viewable, serializable, mousemanipulable, positionable, etc., so instead of making a glyph class we have an interface glyphical which is all of those things. At that point anything from a little widget to some CORBA object that gets signals from outer space can be used in the editor as long as it is glyphical, i.e, walks, acts, and quacks like a glyph. I think this is a very liberating perspective for OO. Still trying to see a downside.

-- MichaelFeathers

-----

CORBA IDL 2 Java mappings ramblings and question

When an interface is articulated in IDL, there are no class definitions, just interfaces. When the idl2java (or like named util) emits the java helper files java interfaces are created for each IDL interface. If one wants to define a class and its methods in IDL then one is faced with choosing an appropriate name, and here is the dilemma. If one defines the class in IDL with the name of the class, then an interface by the same name will get created (which can become quite confusing (even if it is scoped to a package)). Or does one try to avoid using the class name and stick to just adjectives.

-- RicardoClements

-----

I find that in that case, it is best to leave the name of the Interface what you want it to be and then name the class that implements the interface InterfacenameImpl (or some such nonsense). The key here is that since you're utilizing the ProxyPattern, you don't ''want'' clients to know if they have a proxy or a real thing. You should pretty much always type variables to the Interface in that case. The argument in DontDistinguishBetweenClassesAndInterfaces holds well in this case. -- KyleBrown

-----

Lets assume that a company has it all together and actually has a repository of objects (parts, components,....). If the actual implementation of an X is XImpl ,since X is the interface, and a development group wishes to use the class in a non-distributed manner, they would have to created instances of XImpl instead of X. This seems awkward and inelegant.

Also, if the name of the interface was left to be what I wanted it to be (like say ChatClient) then the interface ceases to be an Adjective.

-- RicardoClements

Yes, but if factories are a habit in the org, they may not be making direct instances of XImpl. That is one way out.

Regarding adjectives, I have not seen a downside yet other than what has been mentioned in DontDistinguishBetweenClassesAndInterfaces, and the realization that some adjectives are real horrible bastardizations of nouns. In the JournalOfObjectOrientedProgramming article, I was careful not to advocate. I feel that the whole area deserves further study. In the work that I have done so far, it has been a worthwhile perspective, but I still use nouns for interfaces where it is more natural.

The key thing that I am discovering is that there are interfaces which define partial semantics for an object, that is no one would ever create an Runnable, it is a capability rather than a full class. I find that adjectives and adjectival phrases e.g.,. Can_Contain_Glyphs are useful for specification of generalized capabilities and qualities of reusable objects.

Don't you just envy those hardware engineers? They can just make up acronyms and numbers like MTR751 and be happy.

-- MichaelFeathers

----
I agree with Michael above. There should only be ''one'' place in your system where you create instances of objects if you're using an appropriate Factory pattern - something that CORBA encourages. This means that the fact that the class is actually named "XImpl" is hidden from the rest of your system. The rest of the variables (instance and temporary both) in your system should all be typed to the the Interface. -- KyleBrown

I don't always find there is a need for a class factory. A class factory is appropriate when a child class must be chosen at run-time from available information. There are times, however, that the program flow may allow the child class to be chosen at development time. In this case, a class factory is not beneficial. Both class factory creation and direct object creation have their places in software development. -- WayneMack
----

I think that Java also subtly(?) encourages the X/XImpl idiom by making it possible for package private classes to implement public interfaces. Thus it is very easy to create implementations of the class that simply cannot be accessed outside of their package. -- NicholasJacobs

----

I often think about interfaces as the Roles that an object will take on a different points in its lifetime. i.e. Parent is a role that a person can perform, as is Employee, and to some extent they are a specification of the anonymous side of a relationship between two or more classes.

e.g. Can_Contain_Glyphs could be more concise as GlyphContainer. It's an anonymous object that can contain glyphs. A Runnable is an anonymous object who can be run on a separate thread. Am I making some sense?

-- DionGillard

----

How about using the suffix '-ness' for interfaces based on nouns that do not lend themselves to an obvious adjective. For instance, Squareness, Bookness, Hardness; all interfaces presumably implemented by the Webster's Dictionary on my desk.

''No, no: your Dictionary implements Rectangleness, which is a subtype of Squareness - or is it a supertype?'' We are faced by the following question: is rectangleness a special case of squareness - in which case squareness is the supertype - or is it the other way around?

----

OK, so: a noun is a class, an adjective is an interface, and a verb is a method.

Nobody's mentioned the other parts of speech:

'''Articles''':
	* '''"the"''' would be a Singleton or global, or more generally something that finds the appropriate thing of the type given the current scope
	* '''"a"''' sounds like a Factory to me

'''Adverbs''': these are kind of a catch-all in natural languages, and I think they map to a flurry of things, as well. Adverbs basically answer questions of the forms "how" and "when".
	* many parameters tell how to do something, which makes them adverbs (e.g. open(for_write))
	* (The concrete implementation of a) Strategy is a type of adverb (a Strategy for sorting by date <--> the word "chronologically")
	* a TemplateMethod is a MadLib with all its blanks marked "adverb"
	* an Adapter lets you treat a class with interface A as if it has interface B: so it makes A act "B-ly" (using the GangOfFour example, we'd make a TextView act like a Drawable - that is, act Drawably)

Some of this might be expressible as adjectives, of course: if you shift from saying an object "acts" some way to saying it "is" something, you shift from using adverbs (which modify verbs) to using adjectives (which modify nouns). So it depends which you think is the more natural or useful way to describe an object (my personal feeling is that verbs should remain verbs and nouns should remain nouns, since, as Calvin puts it, "Verbing weirds language").

On further thought, when we talk about making various things "first-class objects" in a language, we're talking about making them (or wrapping them in) nouns. A FunctorObject takes a how (description of behavior) and makes it into a what (a thing that will yield that behavior). Maybe that's not always a good thing; or maybe I'm just confusing model-type objects (which should clearly be nouns) with language objects (which might just be a convenient way to pass around and compose adverbs, verbs, etc.).

-- GeorgePaci

----

I'd weaken the "usually" to "often". Bags of responsibility above a certain size tend to come with titles, and these titles tend to be nouns. An adjective is great for describing one specific property or ability, but not a coordinated set of them. To put it another way, a broader pattern of responsibility of a well-designed interface is a role. To take the classic OO example where your object class is Person (inherits from Primate, inherits from Mammal, etc). Said Person is also Programmer... Programmer should be an interface not another derived class for the obvious reasons (said Person may also be a Jogger, a ModelAirplaneEnthusiast, a BondageFetishist, etc.). Programmer collects together a number of related skills (methods) which make good sense, in context of the workplace (system domain), to be collected together. You could have a bunch of separate interfaces for each skill named by adjective CanWriteCode, CanDesignSoftware, CanTestCode, CanRunBuild but this sort of excessive granularity quickly becomes a maintenance burden just as it would be in the workplace. So a noun that encompasses all those abilities by describing a role makes much more sense, in those situations.

I've also seen programmers come up with all sorts of silly convoluted names trying to stick to this principle.

-----
I think the obvious InterfacesShouldBeVerbs has been missed here! 'Jogs', 'Educates' anyone?

-- ThomasShanks
-----
I saw an alternate convention in a customer's codebase a few years ago. Interface names were sentences like "ICreateWidgets", "ICompareWidgets", "IHaveScreenCoordinates" etc., in first-person narrative from the point of view of the implementing object. By coincidence this makes all interface names start with an "I", matching the DotNet convention. Is this equivalent to InterfacesShouldBeVerbs? Has anyone else seen this?

-- FinnWilcox

''Ha! That's a nice hack on Microsoft's HungarianNotation. (The "I" normally just stands for "Interface".)''
-----
For a contrasting view, see '''InterfacesShouldBeNouns'''.
----
CategoryInterface