hierarchy of interface/implementations.

[horos11]

I had a quick question about implementing interfaces and storing those
implementations..

suppose I have a implementation that I defined:

package mycom;

public interface MyInterface
{
public void mymethod();
}

and I put it in file:

mycom/MyInterface.java


and I want to have several different implementations defined for it,
that I want to stick under:

mycom/MyInterface/Implentation1.java
mycom/MyInterface/Implentation2.java
mycom/MyInterface/Implentation3.java

Can you do this? when I go to make my Implementation1, I say:

package mycom.MyInterface;

I get a conflict, apparently with the interface. But this seems the
logical way to structure things. My workaround is to make a directory:

mycom/MyInterfaceImpl

and stuff all implementations there, but this IMO is a hack and I'm
hoping that there are other ways around this (that make sense, camel
case promotes spelling errors, isn't compiler checkable, etc.)

Any ideas?

Ed

 

[Lew]

I had a quick question about implementing interfaces and storing those
implementations..

suppose I have a implementation that I defined:

package mycom;

public interface MyInterface
{
     public void mymethod();

}

and I put it in file:

mycom/MyInterface.java

and I want to have several different implementations defined for it,
that I want to stick under:

mycom/MyInterface/Implentation1.java
mycom/MyInterface/Implentation2.java
mycom/MyInterface/Implentation3.java

Can you do this? when I go to make my Implementation1, I say:

package mycom.MyInterface;

I get a conflict, apparently with the interface. But this seems the
logical way to structure things. My workaround is to make a directory:

mycom/MyInterfaceImpl

and stuff all implementations there, but this IMO is a hack and I'm
hoping that there are other ways around this (that make sense, camel
case promotes spelling errors, isn't compiler checkable, etc.)

Drop the upper-case letters to lower-case in the package name. That's
more conventional, and will avoid a conflict with type names, which by
convention must have upper-case letters in them.

Forget directories - think in terms of packages and types, then work
out the directories after the fact.

You have more flexibility with names if you have a two-level domain
followed by functional package names.

One-level domain (per your example):

mycom.MyInterface
mycom.impl.Implentation1
mycom.impl.Implentation2
etc.

"MyInterface", "impl" and "ImplementationN" are far too general and
semantically useless names to really show the power, though.

Two-level domain, e.g., lewscanon.com, for a product known as "Killer
App":

com.lewscanon.killerapp.Potable;
com.lewscanon.killerapp.potable.Water;
com.lewscanon.killerapp.potable.Juice;
com.lewscanon.killerapp.potable.Whiskey;

Another way, more structurally bound to the code:

com.lewscanon.killerapp.potable.Potable;
com.lewscanon.killerapp.potable.impl.Water;
com.lewscanon.killerapp.potable.impl.Juice;
com.lewscanon.killerapp.potable.impl.Whiskey;

And the way I usually prefer:

com.lewscanon.killerapp.potable.Potable;
com.lewscanon.killerapp.potable.Water;
com.lewscanon.killerapp.potable.Juice;
com.lewscanon.killerapp.potable.Whiskey;

 

[Mark Space]

mycom/MyInterface.java

...

mycom/MyInterface/Implentation1.java
mycom/MyInterface/Implentation2.java
mycom/MyInterface/Implentation3.java

This SHOULD work. As Eric said, we need to see the actual error message
(and the steps leading up to the error, if you're doing this on the
command line).

Your naming conventions are off, but I can't think of a filesystem off
hand that won't let you name a directory the same as a filename, minus
the extension. They're just two different strings to the filesystem.

You are likely having classpath troubles... post the screen output (or
Ant config, or whatever...) because it's too hard to guess what you are
actually doing incorrectly.

 

[horos11]

I think you mean interface.

yeah, you are right, I am tired..

You appear to be mixing up the package and class names. The class is not
itself a package that you can put things under. (You can nest classes
within another class, but that's an entirely different issue.)

yeah, I sort of gathered that you couldn't do this, but I think that
is more a limitation of java than anything else. You may argue not so
for interfaces, because you can have a class implement many of them
(and hence the 'inheritance' tree is really a bush), but for an
abstract class - or any arbitrary class for that matter - I think it
is a lot clearer to have an inherited class tied to its parent in a
very clear way.

Consider the whole reader design decision in java. I personally think
that

Reader.InputStream

is a lot clearer than

InputStreamReader

because it implicitly shows the relationship between the two classes,
and lends itself to a hierarchy
(like files inside a directory belong to that directory). Likewise,
I'd like to be able to name my class 'File', and hnece say:

Semaphore.File sf = new Semaphore.File()

because I'm using a *type* of Semaphore. I do admit that an abstract
class works better in this case than an interface, but as it is I need
to manually mangle the name to avoid conflict with java's File class.

Anyways, I don't want to make this a big deal, I'll work with it. It's
not like I have any choice.

ed

 

[Joshua Cranmer]

yeah, I sort of gathered that you couldn't do this, but I think that
is more a limitation of java than anything else. You may argue not so
for interfaces, because you can have a class implement many of them
(and hence the 'inheritance' tree is really a bush), but for an
abstract class - or any arbitrary class for that matter - I think it
is a lot clearer to have an inherited class tied to its parent in a
very clear way.

The package structure of Java, namespace structure of C++, and module
structure of Python (among other analogues in other programming
languages) would tend to disagree. It is often desirable to have anyone
extend an interface: for example, java.awt.LayoutManager is a good
example of this. It is implemented more frequently in other packages
than its own java.awt.

Your idea would also work poorly if you have deeper trees. If I want a
JTable, I'd like to be able to say JTable and not
Component.Container.JTable (I'm even skipping JComponent here!). Or how
about Component.Container.Window.Dialog? Most names are already
explanatory of their inheritance: a dialog is obviously a window, a
container, and a component.

Consider the whole reader design decision in java. I personally think
that

Reader.InputStream

is a lot clearer than

InputStreamReader

because it implicitly shows the relationship between the two classes,
and lends itself to a hierarchy
(like files inside a directory belong to that directory).

I disagree. An InputStreamReader is, well, an input stream reader. A
Reader.InputStream is the input stream of a reader (as I read it,
anyways). The use of `.' tends to imply a composition element; for
example, Map.Entry is the entry of a map.

 

[Roedy Green]

package mycom.MyInterface;

I would do it like this:

------------------

// E:\com\mycom\horses\Horse.java
package com.mycom.horses;

interface Horse { .... }

------------

// E:\com\mycom\horses\Palomino.java
package com.mycom.horses;

public class Palomino implements Horse { ... }

------------

// E:\com\mycom\horses\Arabian.java
package com.mycom.horses;

public class Arabian implements Horse { ... }


Note how package names are all lower case, and begin com.

see http://mindprod.com/jgloss/package.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Don’t worry about the world coming to an end today.
It is already tomorrow in Australia."
~ Charles Schulz

 

[Roedy Green]

and I want to have several different implementations defined for it,
that I want to stick under:

mycom/MyInterface/Implentation1.java
mycom/MyInterface/Implentation2.java
mycom/MyInterface/Implentation3.java

Can you do this?

see http://mindprod.com/jgloss/package.html#EXAMPLE
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Don’t worry about the world coming to an end today.
It is already tomorrow in Australia."
~ Charles Schulz

 

[alexandre_paterson]

I had a quick question about implementing interfaces and storing those
implementations..

suppose I have a implementation that I defined:

package mycom;

public interface MyInterface
{
public void mymethod();

}

Hi,

it is *strongly* discouraged to write "public void mymethod();" in
your interface. You can simply write "void mymethod();".

From the definitive authority on the subject, the JLS, which
one in this case cannot argue with:

http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html

"It is permitted, but strongly discouraged as a matter of style,
"to redundantly specify the public modifier for interface methods.

Alex

 

[Lew]

yeah, I sort of gathered that you couldn't do this, but I think that
is more a limitation of java [sic] than anything else. You may argue not so
for interfaces, because you can have a class implement many of them
(and hence the 'inheritance' tree is really a bush), but for an
abstract class - or any arbitrary class for that matter - I think it
is a lot clearer to have an inherited class tied to its parent in a
very clear way.

Java packages are namespaces and not hierarchical.

Consider the whole reader design decision in java. I personally think
that

Reader.InputStream

is a lot clearer than

InputStreamReader

because it implicitly shows the relationship between the two classes,

InputStream dose not depend on Reader, though Readers depend on InputStreams.
The notation 'Reader.InputStream' implies that 'InputStream' is nested
within 'Reader', which is not true.

and lends itself to a hierarchy

Packages are not hierarchical.

(like files inside a directory belong to that directory).
Likewise, I'd like to be able to name my class 'File', and hnece say:

You can most certainly name your class 'File'.

Semaphore.File sf = new Semaphore.File()
because I'm using a *type* of Semaphore.

Well, that isn't Java. It also exposes implementation of the Semaphore, which
in OO is a Bad Thing. You're also stealing the syntax of nested classes.

I do admit that an abstract class works better in this case than an interface,

Does it? Why?

but as it is I need
to manually mangle the name to avoid conflict with java's [sic] File class.

No, you don't. Use the fully-qualified names.

Anyways, I don't want to make this a big deal, I'll work with it. It's
not like I have any choice.

Sure you do. You can use interfaces to hide implementation details instead of
revealing them. You can use packages as they are designed, as
non-hierarchical namespaces. You can name your class 'File' if you wish. If
Java really doesn't do what you want, you can use a different language.

 

[Lew]

I strongly encourage keeping the 'public' in there.


You're right, one cannot argue that it is permitted.

"... cannot argue with ..."

 

[Albert]

(e-mail address removed) a écrit :

Hi,

it is *strongly* discouraged to write "public void mymethod();" in
your interface. You can simply write "void mymethod();".

From the definitive authority on the subject, the JLS, which
one in this case cannot argue with:

http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html

"It is permitted, but strongly discouraged as a matter of style,
"to redundantly specify the public modifier for interface methods.

Since no rationale is given except style, it's not that important.
Keeping public is useful, when you copy/paste method declaration from an
interface to the class which you are implementing. Of course eclipse
quick fix can do the job in most of the cases.

 

[Lew]

(e-mail address removed) a écrit :

Since no rationale is given except style, it's not that important.
Keeping public is useful, when you copy/paste method declaration from an
interface to the class which you are implementing. Of course eclipse
quick fix can do the job in most of the cases.

As a matter of style, I prefer that the interface declarations
explicitly state 'public'. It is less jarring than keeping in mind
different access rules for reading interfaces than for classes, where
absence of an access modifier means "package-private" ("default").
Keeping the 'public' there makes one less alternate rule to remember.
Even without the copy-paste benefit Albert mentioned, cognitive
consistency is an important consideration.