Naming conventions for Interface + Implementation classes?

[Robin Wenger]

As I noticed there are two different naming conventions for an Interface+Implementation pair:

1.) MyClass (=Interface) + MyClassImpl (=Implementation)

or

2.) IMyClass (=Interface) + MyClass (=Implementation)

The first one is (AFAIK) from Sun Who defined originally the second one?

What is recommended (for which scenario)?

Robin

 

[Paul Cager]

I'm responding to an article that was posted to
comp.lang.java.programmer, but with follow-ups set only to
comp.lang.java.help. This article is cross-posted to the two newsgroups. ....
This sort of thing has happened often enough recently that there has to
be some underlying cause. Maybe something can be done to fix it.

Is it something to do with arcor-online.net? That seems to be a common
factor, though it could just be coincidence.

 

[Lew]

Reposting to include c.l.j.p because I didn't notice the original
message had idiotically been set for follow-ups only to c.l.j.h.

Robin Wenger has had pushback on the cross-posting issue several times
before, but apparently has decided not to comply with the multiple
requests to clean up their act.


As Pete noted, neither is really conventional.

Idiots.

The second one, never. The use of 'Impl' for an implementing class is
sometimes used pedagogically when the topic is interfaces and their
implementations. In production code, both of those so-called
"conventions" violate the principle of names that make sense in the
problem domain.

I don't think you'll find anyone using the word "Class" in an interface
name, nor the suffice "Impl" in the name of a class that implements an
interface.

Unless they use "Impl" in a discussion to emphasize coding principles,
but generally Pete has the right of it.

So on the face of the it, the question doesn't make much sense.

In Java, what I often see with respect to interfaces and implementations
are names like "MyInterface" and "MySpecificKindOfMyInterface".  E.g.
List vs ArrayList, Set vs HashSet, etc.

That said, if you're mainly asking about whether to use a leading 'I' on
interface names or not, hard-core Java purists are unlikely to find that
kosher.  It's a convention followed in .NET and in the Windows API for
COM interfaces (and possibly Delphi, and other languages…), but I've
never seen it in any "official" Java code.

The Sun conventions suggest the use of names that are sensible in the
problem domain.
"Class names should be nouns, in mixed case with the first letter of
each internal word capitalized. Try to keep your class names simple
and descriptive. Use whole words-avoid acronyms and abbreviations
(unless the abbreviation is much more widely used than the long form,
such as URL or HTML)."
<http://www.oracle.com/technetwork/java/
codeconventions-135099.html#367>
There's nothing in there about using "Class" (TERRIBLE idea!) or
"Impl" as part of a type name, and the examples there don't show such
a thing.

Naming a type (forget class or interface - think "type") with
implementation details ("I" for interface, "Impl" for class) violates
the O-O principle to hide implementation and is a stupid idea. It
benefits nothing, it imposes extra work if you change implementation
(one of the motivators for black-boxing implementation) to avoid
misleading nomenclature, and it bespeaks a lack of critical-thinking
capacity.

 

[Tom Anderson]

I see it a lot in Microsoft land, so perhaps it originated there - they're
certainly fond of pseudo-Hungarian notation elsewhere, and this is
similar. I recall Delphi also had prefix letters (TSomeComponent and so
on); i don't know if this is related.

I don't think you'll find anyone using the word "Class" in an interface
name,

I assume that MyClass is a metasyntactic variable here.

nor the suffice "Impl" in the name of a class that implements an
interface.

You're kidding me, right? Try this on for size:

$ cd $JAVA_HOME
$ find . -type f -name \*.jar -print0 | xargs -0 -n1 jar tf | egrep "Impl.class$" | sort -u

With 1.6.0_22, that nets me 1423 hits. Now, not all of these are classes
which follow the pattern ${InterfaceName}Impl, but enough are to disprove
your belief.

In fact, let's see a bunch:

$ cd $JAVA_HOME
$ export CLASSPATH=$(find . -name \*.jar | tr '\n'
$ find . -type f -name \*.jar -print0 | xargs -0 -n1 jar tf \
| egrep "Impl.class$" | fgrep -v '$' | cut -d . -f 1 | tr / . \
| sort -u \
| while read c; do
iface=$(javap $c 2>/dev/null | egrep -o "implements [a-zA-Z0-9.]*" | cut -d ' ' -f 2);
if [[ $iface == ${c%%Impl} ]]; then
echo "$c implements $iface";
fi;
done

And that's a rough survey which ignores anything involving inner classes,
implementations which are in different packages to their interfaces, any
kind of addition to the class name, classes implementing another interface
ahead of their namesake, etc.

I hasten to add that i do not recommend this naming convention; i'm simply
demonstrating that it does occur in the wild.

In Java, what I often see with respect to interfaces and implementations
are names like "MyInterface" and "MySpecificKindOfMyInterface". E.g.
List vs ArrayList, Set vs HashSet, etc.

Yup. That's the right way to do it.

tom

 

[Lew]

[...]
Naming a type (forget class or interface - think "type") with
implementation details ("I" for interface, "Impl" for class) violates
the O-O principle to hide implementation and is a stupid idea.  It
benefits nothing, it imposes extra work if you change implementation
(one of the motivators for black-boxing implementation) to avoid
misleading nomenclature, and it bespeaks a lack of critical-thinking
capacity.

See Robin?  Told you so.  

Personally, given the fundamental distinction between how one can use an
interface and a class (and in particular, the inheritability of either),
I see nothing wrong with 'I' for interface, and even find it helpful.  I
also feel I have above-average critical-thinking capacity, though
obviously Lew disagrees.

But he and others will impugn whomever they need to in order to support
their blind faith in Sun's conventions.  Ignore their dogma at your own
risk!  Heaven forbid you should actually post any code here that doesn't
comply.  Lew will pick it to pieces, leaving nothing but shredded ego
and a bit of "for" loop here, a smidgen of inner class there.

Christ, Pete!

Well, I guess it's all right to shred the messenger if you can't
really speak to the message.

I have not said anything about "faith" in the conventions. The OP's
question was explicitly about the naming conventions. How can I
answer that without reference to the conventions documentation, hm?
Riddle me that!

I know you have contempt for the conventions; you said as much in your
earlier post:
"I do all sorts of things, naming- and formatting-wise, in Java that
Java purists hate. "

So your bias is well known.

But the OP did ask about conventions, and the conventions are as I
stated.

As for their value, well, the key in Java programming really is
types. There is a widespread practice, as you stated, of naming an
interface vs. a class (correcting your example) as "MyType" and
"MySpecificKindOfMyType". The type names are supposed to represent
functionality in the domain of discourse, so 'List' is the general
contract for a certain collection type and 'ArrayList' is a subtype
with specific properties. The names indicate the problem-domain
(collections) characteristics.

I'm not going to get into a snarky religious war with you, Pete.
Flame away to your heart's content. I presented the case against
Hungarian-style notational warts (they violate information hiding).
If you want to present the case in their favor, that provides balance
for those making a critical decision. If they want to base that
decision on your statement that I'm picky, then they are using
irrelevant criteria, so why even proffer such?

Maybe it's that lack of critical thinking ...

 

[Arne Vajhøj]

As I noticed there are two different naming conventions for an Interface+Implementation pair:

1.) MyClass (=Interface) + MyClassImpl (=Implementation)

or

2.) IMyClass (=Interface) + MyClass (=Implementation)

The first one is (AFAIK) from Sun Who defined originally the second one?

What is recommended (for which scenario)?

The second is part of the common hungarian naming
convention used in Windows C/C++ programming. Especially
in COM programming the IThingys are everywhere. .NET
ditched hungarian naming convention in general but kept
it for interfaces. Possibly to make it easier for
interop with COM. But very much a MS convention. It
is very rare to see it in the Java world (even though I
think there is somewhere it is used).

The first is the convention introduced by SUN for Java RMI.
Some people have suggested it being used for Java
in general, but that idea has never caught on. It is used
for RMI and not for anything else in the Java world. I
don't think I have seen it used outside of Java.

The Java coding convention:
http://www.oracle.com/technetwork/java/codeconventions-135099.html#367
just specify plain nouns in mixed case for both classes
and interfaces.

I think it is relative common for an interface Foo to
have implementing classes be either FooBar or BarFoo where
Bar somehow indicates something about the implementation.

Arne

 

[Arne Vajhøj]

I don't think you'll find anyone using the word "Class" in an interface
name, nor the suffice "Impl" in the name of a class that implements an
interface.

It is very common for RMI.

Arne

 

[Arne Vajhøj]

Peter Duniho wrote:


As Pete noted, neither is really conventional.


The second one, never. The use of 'Impl' for an implementing class is
sometimes used pedagogically when the topic is interfaces and their
implementations. In production code, both of those so-called
"conventions" violate the principle of names that make sense in the
problem domain.



Unless they use "Impl" in a discussion to emphasize coding principles,
but generally Pete has the right of it.

Not doing much RMI coding??



Arne

 

[Esmond Pitt]

I don't think you'll find anyone using the word "Class" in an interface
name, nor the suffice "Impl" in the name of a class that implements an
interface.

MyRemoteImpl is widely used in RMI systems, which are not themselves
widely used ;-). For example sun.rmi.server.RegistryImpl. I never liked it.

 

[Lew]

Not doing much RMI coding??

I said "generallY"! RMI is a special case and its domain of discourse is
programming to begin with.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Mike Schilling]

The second is part of the common hungarian naming
convention used in Windows C/C++ programming. Especially
in COM programming the IThingys are everywhere. .NET
ditched hungarian naming convention in general but kept
it for interfaces. Possibly to make it easier for
interop with COM. But very much a MS convention. It
is very rare to see it in the Java world (even though I
think there is somewhere it is used).

The first is the convention introduced by SUN for Java RMI.
Some people have suggested it being used for Java
in general, but that idea has never caught on. It is used
for RMI and not for anything else in the Java world. I
don't think I have seen it used outside of Java.

The Java coding convention:
http://www.oracle.com/technetwork/java/codeconventions-135099.html#367
just specify plain nouns in mixed case for both classes
and interfaces.

I think it is relative common for an interface Foo to
have implementing classes be either FooBar or BarFoo where
Bar somehow indicates something about the implementation.

Also for an abstract base class for implementations of Foo to be called
AbstractFoo.