2

I ran into some Java code at work today :

public interface A {

    public static interface AObj {
         String toXml();
         int getCode();
    }

    public static interface AMap {
         String toXml();
         int blah();
    }
    ...
}

I have not encountered having static interfaces embedded in an existing interface before. It doesn't make much sense. Can someone comment on :

a) Is this good design practice b) What the benefits are to this vs Having individual interface files. c) This was written by a c++ programmer, i get the impression they're trying to re-create namespaces. If that's the case, why not just use packages ?

Any comments most welcome.

Regards, Alistair.

AlMcLean
  • 3,459
  • 2
  • 19
  • 14
  • 3
    You don't need the `public` and `static` keywords inside an interface as they are implicit! – adarshr Feb 22 '12 at 12:14
  • I have never seen a need to do anything like this with interfaces. Inner classes have value but I don't see the benefits of this with interfaces. I think you're right that they were trying to re-create namespaces. Packages should be sufficient in 99.9999% of all cases. – Joe Feb 22 '12 at 12:21
  • Here's a very simmilar question: http://stackoverflow.com/questions/71625/why-would-a-static-inner-interface-be-used-in-java – david a. Feb 22 '12 at 12:26

2 Answers2

2

Good/bad practice can be debatable. Typically one would nest interfaces if the nested interface is an inseparable entity in relation to its parent.

Take a look at the source code of java.util.Map. It merrily embeds Map.Entry inside it. The author is Josh Bloch, who is definitely not an inexperienced Java developer. So I'm sure there must be a valid reasoning behind designing the interface that way.

Here is what it looks like (JavaDoc and comments stripped).

public interface Map<K,V> {
    int size();
    boolean isEmpty();
    boolean containsKey(Object key);
    boolean containsValue(Object value);
    V get(Object key);
    V put(K key, V value);
    V remove(Object key);
    void putAll(Map<? extends K, ? extends V> m);
    void clear();
    Set<K> keySet();
    Collection<V> values();
    Set<Map.Entry<K, V>> entrySet();

    interface Entry<K,V> {
        K getKey();
        V getValue();
        V setValue(V value);
        boolean equals(Object o);
        int hashCode();
    }

    boolean equals(Object o);
    int hashCode();
}
adarshr
  • 61,315
  • 23
  • 138
  • 167
  • You should look at this [same question](http://stackoverflow.com/questions/71625/why-would-a-static-inner-interface-be-used-in-java). The comment of @Paŭlo Ebermann complete the answer of adarshr. >"A nested interface is automatically static, whether one writes the keyword or not" – diodfr Feb 22 '12 at 12:24
  • Thanks, i guess I would just need to work out why the decision was made. I guess I would always just put separate interfaces in different files. – AlMcLean Feb 22 '12 at 12:42
0

First of all, you don't have to type public or static as adarshr stated (see comment). Regarding inner interfaces: everything depends on the context in which they are used- for example GWT requires to expose interface describing application styles for cell lists. I have one interface for general devices, and inner interfaces extending it for some specific devices (android, iphone and so on). It's a less messy in my opinion, especially that all these interfaces for specific devices contains one method overriding default behavior.

However, if interfaces are not so tighly coupled as in the example mentioned above, I'd rather put them in a separate files. Of course, it's your choice depending on design.

omnomnom
  • 8,911
  • 4
  • 41
  • 50