Практическая сторона способности определить класс в интерфейсе в Java?

Я думаю, что эта страница объясняет один пример вполне прилично. Вы использовали бы его для трудной привязки определенного типа с интерфейсом.

Бесстыдно сорванный из вышеупомянутой ссылки:

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

В вышеупомянутом интерфейсе Вы связываете Ролевой тип сильно с интерфейсом сотрудника (сотрудник. Роль).

Одно использование (что бы там ни было) было бы как обходное решение для того, что Java не поддерживает статические методы в интерфейсах.

interface Foo {
    int[] getData();

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

Затем Вы назвали бы его с:

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

Я могу сказать без колебания, что никогда не делал этого. Я не могу думать о причине, почему Вы были бы также. Классы вкладываются в классах? Несомненно, много причин сделать это. В тех случаях я склонен полагать, что те внутренние классы деталь реализации. Очевидно, интерфейс не имеет никаких деталей реализации.

Я предполагаю, что Вы могли определить класс, который используется в качестве типа возврата или типа параметра для методов в интерфейсе. Не кажется особенно полезным. Вы могли бы также просто определить класс отдельно. Единственное возможное преимущество состоит в том, что это объявляет класс как "принадлежащий" интерфейсу в некотором смысле.

Google Web Toolkit использует такие классы для привязки 'нормального' интерфейса с интерфейсом асинхронного вызова:

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() {
            ...
        }
    }
}

Одно место эта идиома используется в большой степени, находится в XMLBeans. Цель того проекта состоит в том, чтобы взять XML-схему и генерировать ряд классов Java, которые можно использовать двунаправлено для работы с XML-документами, соответствующими схеме. Так, это позволяет Вам проанализировать XML в xml бобы или создать xml бобы и произвести к xml.

В целом большинство типов схемы XML отображается на интерфейсе Java. Тот интерфейс имеет в нем Фабрику, которая используется для генерации экземпляров того интерфейса в реализации по умолчанию:

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
  }
} 

Когда я сначала встретился с этим, казалось неправильным связать все это месиво реализации в интерфейсное определение. Однако я на самом деле вырос для симпатии его, поскольку это позволило всему определяться с точки зрения интерфейсов, но иметь универсальный способ получить экземпляры интерфейса (в противоположность наличию другой внешней фабрики / класс разработчика).

Я взял его для классов, где этот имевший смысл (особенно они, где я серьезно контролировал interface/impls) и нашел, что это было довольно чисто.

Со статическим классом в интерфейсе у Вас есть возможность сократить общий фрагмент программирования: Проверка, если объект является экземпляром интерфейса и раз так вызовом метода этого интерфейса. Посмотрите на этот пример:

public interface Printable {
    void print();

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

Теперь вместо того, чтобы делать это:

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

Можно записать:

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

Я подчеркнул бы осторожность каждый раз, когда это походит на хорошую идею создать нечастный вложенный класс. Вы - почти наверняка более обеспеченное движение прямо для внешнего класса. Но если Вы собираетесь создать вложенный класс общественности, больше не кажется странным поместить его в интерфейс, чем класс. Абстрактность внешнего класса не обязательно связана с абстрактностью вложенного класса.

Выполнение этого, кажется, имеет "Плохое проектное решение", записанное на всем протяжении его.

Этот подход может использоваться для определения многих классов в том же файле. Это работало хорошо на меня в прошлом, где у меня есть много простых реализаций интерфейса. Однако, если бы я должен был сделать это снова, то я использовал бы перечисление, которое реализует интерфейс, который был бы более изящным решением.