Win a copy of Machine Learning Systems: Designs that scale this week in the Scala forum
or Xamarin in Action: Creating native cross-platform mobile apps in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Interface & Implementation Naming Pattern  RSS feed

 
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I have been using for the interface would be named something like

SomeService.java

and the implementation as

SomeServiceImpl.java

I've also seen several instances of ISomeService and then SomeService for the impementation. But I personally am not a fan of prefixing with I. What is "standard" or is there one?
 
Ranch Hand
Posts: 657
Clojure Spring VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

What is "standard" or is there one?

I've seen a bunch of the "Impl" idiom, but I'm not a big fan of that either. I try as best I can to give the implementations descriptive names, such as a clue about the platform or something along those lines (e.g., "SomeBusObjMySQLDAO"). Sometimes it's tough to find good names, but I tend to prefer the more descriptive variety over the previously-mentioned conventions.

But then, I'm pretty much the only one who has to look at my stuff. Hopefully "The Next Guy"� agrees with me...
 
Ranch Hand
Posts: 1149
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
<My Opinion>
There's no denying that the I... convention is certainly efficient. Let's face it, there's no mistaking which classes are interfaces and which aren't.

BUT I prefer names that sound more like real words so that my sentences sound reasonable when I translate a class diagram into English. e.g. I'd rather say, "a Vector is Serializable and Clonable," or, "a DefaultTableModel is a TableModel."

Contrast those to the situation wherre the I... convention is used: "A Vector is ISerializable and IClonable," or, "a TableModel is an ITableModel." Ugh. ISerializable isn't a word.

One last thing against the I... convention: The standard Java classes don't follow that convention, so using it would mean introducing something new when there's already a "perfectly good" convention in place.
</My Opinion>
 
author and iconoclast
Sheriff
Posts: 24219
40
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is just my general practice, not any kind of pronouncement:

I think the "ISomeService" thing is popular with people who came down via Microsoft tools; I've never used it. If an interface has only one implementation, I'll use the XImpl convention if the class is private and lives behind a factory; otherwise I'll name it something like "DefaultX". Most of the time, you end up with multiple implementations of an interface, and so XImpl doesn't work -- you have instead FooX and BarX and maybe DefaultX.
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The IConvention seems to be used to implement the "how I do it" then "what am I going to do", antipattern. That is, the developer thinks in terms of classes (how I do it), then defines the corresponding interface (what am I going to do). Too often, novices fail to think in terms of interfaces, and even when they do, they stop far short of the optimal. The interface *is* the type. The implementation is entirely irrelevant; in fact, it should exposes nothing more than a static factory method (who cares about the rest of the details?) that returns the interface reference type. This can be achieved by declaring all constructors private.
 
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Tony Morris:
The IConvention seems to be used to implement the "how I do it" then "what am I going to do", antipattern. That is, the developer thinks in terms of classes (how I do it), then defines the corresponding interface (what am I going to do).



I wonder how you come to this conclusion, as it totally contradicts my personal experience.

We use the ISomething convention at work. At first I was against it, for exactly the reasons already mentioned.

Since that time I got used to it, and actually started to like it. Interestingly I find that it *helps* us writing the code in terms of "implement against interfaces". With the naming convention it is quite easy to spot places where interfaces aren't used, and to fix them if appropriate.

With other words, since we adopted that naming convention, you will here much more often "eek, why isn't there an interface used here?" I think of that as a benefit.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So what I am getting from all this is it follows the same pattern as code styles. Conventions are either personal preference or company guided. Thanks for everyone's input.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24219
40
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
With the naming convention it is quite easy to spot places where interfaces aren't used, and to fix them if appropriate.



That's a good point, Ilja, and something for me to think about!
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


With the naming convention it is quite easy to spot places where interfaces aren't used, and to fix them if appropriate.


You're assuming the use of some tool I guess, since I can "spot them" just as easily as you can with some other tool and an arbitrary naming convention.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ernest Friedman-Hill:


That's a good point, Ilja, and something for me to think about!



+1. That is a good point. But the convention still doesn't sit right. Not to mention it kind of breaks camel case rules. Although it wouldn't be a big deal to just adopt it and get used to it. But for the sake of conversation, what are some other conventions that could be used to get the same effect.

package structure: com.gthought.app.interface; where all files in this package are interfaces.

I suffix - TableModelI (ok, that's worse than ITableModel.

What else you got?
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


What else you got?


A programming language that provides a proper separation of implementation and contract, thus invalidating the whole "hoe do you name it?" thing. Well, not yet...
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Tony Morris:

You're assuming the use of some tool I guess, since I can "spot them" just as easily as you can with some other tool and an arbitrary naming convention.



Not really. Look at this list and tell me where the interfaces are:

CategoryDAO
TypeDAO
CategoryService
EmailService

Now look at this list and tell me

ICategoryDAO
ITypeDAO
ICategoryService
IEmailService

At a glance, I agree with Ilja but for me the convention is still strange.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ew yuk puke guk!
I guess this is one more of those sentiment reigns over science things.
There's not much I can say, or at least, am prepared to say, to change anything.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Tony Morris:

A programming language that provides a proper separation of implementation and contract, thus invalidating the whole "hoe do you name it?" thing. Well, not yet...



Not in Java, at least. I agree that in a different language, I'd probably use different naming conventions.

But I'm curious - what would such a language look like?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:
But the convention still doesn't sit right. Not to mention it kind of breaks camel case rules. Although it wouldn't be a big deal to just adopt it and get used to it.



Yes, I can fully relate to those feelings. Before we adopted the convention, I was convinced that I had some really good arguments against it. I had to learn the hard way that I mostly invented them to justify keeping what I was used too...

package structure: com.gthought.app.interface; where all files in this package are interfaces.





In my opinion, an interface most closely belongs to its client, so they should likely be put together.

Of course there are interfaces that are so commonly used that you simply can't group them with all there clients. In that case I agree with Tony: the interfaces are the central part, the implementation should be hidden away. So I'd prefer to put interfaces in com.gthought.app, for example, and the implementation in com.gthought.app.defaultimpl or something...
 
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I vote for the I prefix and hate "Impl". I was just working yesterday with interface IDataStore and classes MockDataStore, MemoryDataStore and FileSystemDataStore. DataStoreImpl communicates nothing to me, and what will you call the second one? DataStoreOtherImpl? SonOfDataStoreImpl? I'm teasing of course. It could be FileSystemDataStoreImpl ... but ... why?

By the way, I think "IDatastore" reads quite nicely. You have to plant your feet firmly, say it with conviction and pound on your chest, but it works for me.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Stan James:

By the way, I think "IDatastore" reads quite nicely. You have to plant your feet firmly, say it with conviction and pound on your chest, but it works for me.



ROFL!
 
Ryan McGuire
Ranch Hand
Posts: 1149
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:


+1. That is a good point. But the convention still doesn't sit right. Not to mention it kind of breaks camel case rules. Although it wouldn't be a big deal to just adopt it and get used to it. But for the sake of conversation, what are some other conventions that could be used to get the same effect.

package structure: com.gthought.app.interface; where all files in this package are interfaces.

I suffix - TableModelI (ok, that's worse than ITableModel.

What else you got?



But you don't use camel case for class names. Prefixing an I won't break anything.

I disagree that TableModelI is worse than ITableModel. Using a suffix makes it sound better (in English). For example I'd much rather have a TableModelI than an ITableModel. "TableModel" is an adjective modifying the noun "I".

But is there something better than just plain "I" as a suffix? How about "Int", "Inter", "Intf", or "Interf"? (The third cound be pronounced "interface".)

If introducing a new convention imposed no extra overhead, I think TableModelIntf is a reasonable alternative to ITableModel, and it has the "identify interfaces at a glance" benefit Ilja mentioned.
[ August 31, 2005: Message edited by: Ryan McGuire ]
 
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My two cents...

Don't use any kind of naming that specifies something about the class or interface. This is the path that results in Hungarian Notation and results in horrible looking names like $_i32_p_fWndHndl. Ugh. People in this thread can't even stand a simple "I" prefix...why do anything that leads down that path?

No, the better solution is to have a good tool. Don't develop in Notepad--use IntelliJ or Eclipse. A good IDE can tell you everything you need to know about a variable...I believe you can even colorize them differently to make it obvious.

The real solution to this problem is proper architecture and design. If a project is written such that dependencies are managed correctly, then that means there are no circular dependencies at any level of granularity (class, package, project, etc). To do this, highly stable parts of the system should be separated from the rest of the code. This can be done by using interfaces, abstract factories, and packaging things properly.

It's nice that the convention of prefixing an "I" can cause developers to notice that things aren't being done correctly, but simply modifying a reference to be of an interface type doesn't really do anything if that interface isn't packaged correctly in the first place.

So I tend to think of this stripped-down kind of Hungarian Notation as a band-aid to mitigate larger problems. Like when someone says, "Prefer composition to inheritance"--this is bad advice--one ought to prefer composition when composition is called for, and inheritance when inheritance is called for. Following this dictum is a means to avoid learning how to properly use composition and inheritance for one more day. If the Holy Grail of OO development was simply doing away with inheritance, the good people at Sun would've taken it out of Java when they designed the language.

This is how I view the "I" prefix. Don't declare the type of your references randomly and you'll never run into a problem where you've accidentally used a class as a reference type instead of an interface.
 
Crusading Chameleon likes the size of this ad:
Rocket Oven Kickstarter - from the trailboss
https://coderanch.com/t/695773/Rocket-Oven-Kickstarter-trailboss
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!