Practical side of the ability to define a class within an interface in Java?

Question

What would be the practical side of the ability to define a class within an interface in Java:

interface IFoo
{
    class Bar
    {
        void foobar ()
        {
            System.out.println("foobaring...");
        }
    }
}

Enschede

Answer 1

I can think of another usage than those linked by Eric P: defining a default/no-op implementation of the interface.

./alex

interface IEmployee
{

    void workHard ();  
    void procrastinate ();

    class DefaultEmployee implements IEmployee 
    {
        void workHard () { procrastinate(); };
        void procrastinate () {};
    }

}

Yet another sample — implementation of Null Object Pattern:

interface IFoo
{
    void doFoo();
    IFoo NULL_FOO = new NullFoo();

    final class NullFoo implements IFoo
    {
        public void doFoo () {};
        private NullFoo ()  {};
    }
}


...
IFoo foo = IFoo.NULL_FOO;
...
bar.addFooListener (foo);
...

Width

@Totophil: glad that you got the idea and thanks for enhancing my answer . @Herms: glad you like it! – Width

Commonly Null Object could be a singleton too since it doesn't hold into any state nor mutates any other objects - this is actually great answer since I'm going to start doing things like this from now on, this is smart! – Harrington

whoa. never heard of it, but it rocks! – Ximenez

Answer 2

I think this page explains one example pretty well. You would use it to tightly bind a certain type to an interface.

Shamelessly ripped off from the above link:

interface employee{
    class Role{
          public String rolename;
          public int roleId;
     }
    Role getRole();
    // other methods
}

In the above interface you are binding the Role type strongly to the employee interface(employee.Role).

Vaccine

Answer 3

One use (for better or worse) would be as a workaround for the fact that Java doesn't support static methods in interfaces.

interface Foo {
    int[] getData();

    class _ {
        static int sum(Foo foo) {
            int sum = 0;
            for(int i: foo.getData()) {
                sum += i;
            }
            return sum;
        }
    }
}

Then you'd call it with:

int sum = Foo._.sum(myFoo);

Wolcott

That is so worse that I have to up vote it. I love this kind of experiments. – Lombardo

Answer 4

I can say without hesitation that I've never done that. I can't think of a reason why you would either. Classes nested within classes? Sure, lots of reasons to do that. In those cases I tend to consider those inner classes to be an implementation detail. Obviously an interface has no implementation details.

Penman

Answer 5

One place this idiom is used heavily is in XMLBeans. The purpose of that project is to take an XML Schema and generate a set of Java classes that you can use bidirectionally to work with XML documents corresponding to the schema. So, it lets you parse XML into xml beans or create the xml beans and output to xml.

In general, most of the xml schema types are mapped to a Java interface. That interface has within it a Factory that is used to generate instances of that interface in the default implementation:

public interface Foo extends XmlObject {
  public boolean getBar();
  public boolean isSetBar();
  public void setBar(boolean bar);

  public static final SchemaType type = ...

  public static final class Factory {
    public static Foo newInstance() {
      return (Foo)XmlBeans.getContextTypeLoader().newInstance(Foo.type, null);
    }

    // other factory and parsing methods
  }
} 

When I first encountered this it seemed wrong to bind all this implementation gunk into the interface definition. However, I actually grew to like it as it let everything get defined in terms of interfaces but have a uniform way to get instances of the interface (as opposed to having another external factory / builder class).

I picked it up for classes where this made sense (particularly those where I had a great deal of control over the interface/impls) and found it to be fairly clean.

Clie

Answer 6

I guess you could define a class that is used as the return type or parameter type for methods within the interface. Doesn't seem particularly useful. You might as well just define the class separately. The only possible advantage is that it declares the class as "belonging" to the interface in some sense.

Eddaeddana

Answer 7

Google Web Toolkit uses such classes to bind 'normal' interface to asynchronous call interface:

public interface LoginService extends RemoteService {

    /**
     * Utility/Convenience class.
     * Use LoginService.App.getInstance() to access static instance of LoginServiceAsync
     */
    class App {

        public static synchronized LoginServiceAsync getInstance() {
            ...
        }
    }
}

Plumbic

Answer 8

With a static class inside an interface you have the possibility to shorten a common programming fragment: Checking if an object is an instance of an interface, and if so calling a method of this interface. Look at this example:

public interface Printable {
    void print();

    public static class Caller {
        public static void print(Object mightBePrintable) {
            if (mightBePrintable instanceof Printable) {
                ((Printable) mightBePrintable).print();
            }
        }
    }
}

Now instead of doing this:

void genericPrintMethod(Object obj) {
    if (obj instanceof Printable) {
        ((Printable) obj).print();
    }
}

You can write:

void genericPrintMethod(Object obj) {
   Printable.Caller.print(obj);
}

Procyon

Answer 9

Doing this seems to have "Bad design decision" written all over it.

Liquidate

Answer 10

I would urge caution whenever it seems like a good idea to create a non-private nested class. You are almost certainly better off going straight for an outer class. But if you are going to create a public nested class, it doesn't seem any more strange to put it in an interface than a class. The abstractness of the outer class is not necessarily related to the abstractness of a nested class.

Britten

Answer 11

This approach can be used to define many classes in the same file. This has worked well for me in the past where I have many simple implementations of an interface. However, if I were to do this again, I would use an enum which implements an interface which would have been a more elegant solution.

Caddy

hide comments I was thinking about implementation through enum as well, but since any enum is effectively a collection of singletons I was struggling to think of any real life samples there anyone would like a bunch of "default" singletons implementating for the same interface. – Enschede