hierarchy of interface/implementations.

Discussion in 'Java' started by horos11@gmail.com, Mar 24, 2009.

  1. Guest

    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
    , Mar 24, 2009
    #1
    1. Advertising

  2. Lew Guest

    On Mar 24, 5:29 pm, wrote:
    > 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;

    --
    Lew
    Lew, Mar 24, 2009
    #2
    1. Advertising

  3. Mark Space Guest

    wrote:
    >
    > 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.
    Mark Space, Mar 24, 2009
    #3
  4. Guest

    On Mar 24, 3:00 pm, "Matt Humphrey" <> wrote:
    > <> wrote in message
    >
    > news:...>I had a quick question about implementing interfaces and storing those
    > > implementations..

    >
    > > suppose I have a implementation that I defined:

    >
    > I think you mean interface.
    >


    yeah, you are right, I am tired.. :)
    >
    >
    > > 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

    > 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
    , Mar 25, 2009
    #4
  5. wrote:
    > 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.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Mar 25, 2009
    #5
  6. Roedy Green Guest

    On Tue, 24 Mar 2009 14:29:41 -0700 (PDT), wrote,
    quoted or indirectly quoted someone who said :

    >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, Mar 25, 2009
    #6
  7. Roedy Green Guest

    On Tue, 24 Mar 2009 14:29:41 -0700 (PDT), wrote,
    quoted or indirectly quoted someone who said :


    >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
    Roedy Green, Mar 25, 2009
    #7
  8. Guest

    On Mar 24, 9:29 pm, wrote:
    > 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
    , Mar 25, 2009
    #8
  9. Lew Guest

    wrote:
    > 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
    Lew, Mar 25, 2009
    #9
  10. Lew Guest

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

    >
    > I strongly encourage keeping the 'public' in there.
    >
    >> 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.

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


    "... cannot argue with ..."

    --
    Lew
    Lew, Mar 25, 2009
    #10
  11. Albert Guest

    a écrit :
    > On Mar 24, 9:29 pm, wrote:
    >> 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.


    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.
    Albert, Mar 25, 2009
    #11
  12. Lew Guest

    a écrit :
    >> 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.

    >


    Albert wrote:
    > 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.

    --
    Lew
    Lew, Mar 25, 2009
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marcus Crafter
    Replies:
    1
    Views:
    345
    Mike Schilling
    Feb 19, 2004
  2. Sparko

    Interface implementations

    Sparko, Mar 2, 2004, in forum: Java
    Replies:
    4
    Views:
    350
    Christophe Vanfleteren
    Mar 2, 2004
  3. z-man
    Replies:
    15
    Views:
    597
    Chris Uppal
    Oct 11, 2006
  4. Lorenzo Castelli

    Interface hierarchy emulation

    Lorenzo Castelli, Aug 21, 2005, in forum: C++
    Replies:
    2
    Views:
    309
    Lorenzo Castelli
    Aug 21, 2005
  5. Chris
    Replies:
    2
    Views:
    308
    Chris
    Mar 15, 2007
Loading...

Share This Page