Почему статический вложенный интерфейс использовался бы в Java?
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
8 ответов
Статическое ключевое слово в вышеупомянутом примере избыточно (вложенный интерфейс автоматически "статичен"), и может быть удален без эффекта на семантику; я рекомендовал бы, чтобы это было удалено. То же идет для "общественности" на методах интерфейса и "общедоступном финале" на интерфейсных полях - модификаторы избыточны и просто добавляют помеху к исходному коду.
Так или иначе, разработчик просто объявляет интерфейс по имени Foo. Панель. Нет никакой дальнейшей связи с классом включения, за исключением того, что код, который не может получить доступ к Foo, не будет в состоянии получить доступ к Foo. Панель также. (От исходного кода - байт-код или отражение могут получить доступ к Foo. Панель, даже если Foo является частным на пакет!)
Это - приемлемый стиль для создания вложенного интерфейса этот путь, если Вы ожидаете, что он будет использоваться только от внешнего класса, так, чтобы Вы не создавали новое имя верхнего уровня. Например:
public class Foo {
public interface Bar {
void callback();
}
public static void registerCallback(Bar bar) {...}
}
// ...elsewhere...
Foo.registerCallback(new Foo.Bar() {
public void callback() {...}
});
На вопрос ответили, но одно серьезное основание использовать вложенный интерфейс состоит в том, если его функция непосредственно связана с классом, это находится в. Хороший пример этого Listener. Если бы у Вас было класс Foo, и Вы хотели, чтобы другие классы были в состоянии прислушаться к событиям на нем, Вы могли объявить интерфейс, названный FooListener, который в порядке, но это, вероятно, было бы более ясно объявить вложенный интерфейс и иметь те другие классы реализация Foo.Listener (вложенный класс Foo.Event не плох наряду с этим).
Членские интерфейсы неявно статичны. Статический модификатор в Вашем примере может быть удален, не изменяя семантику кода. См. также Спецификацию языка 8.5.1 Java. Статические Объявления Типа элемента
Внутренний интерфейс должен быть статичным для доступа. Интерфейс не связан с экземплярами класса, но с самим классом, таким образом, к этому получили бы доступ с Foo.Bar, как так:
public class Baz implements Foo.Bar {
...
}
большинством способов, это не отличается от статического внутреннего класса.
Для ответа на вопрос очень непосредственно посмотрите на Карту. Запись.
также это может быть полезно
Обычно я вижу статические внутренние классы. Статические внутренние классы не могут сослаться на содержание классов wherease, нестатические классы могут. Если Вы не сталкиваетесь с некоторыми коллизиями пакета (там, уже интерфейс под названием Панель в том же пакете как Foo), я думаю, что сделал бы его своим собственным файлом. Это могло также быть проектное решение осуществить логическое соединение между Foo и Панелью. Возможно, автор предназначил Панель, которая только будет использоваться с Foo (хотя статический внутренний интерфейс не осуществит это, просто логическое соединение)
В Java статический интерфейс/класс позволяет интерфейсу/классу использоваться как класс верхнего уровня, то есть, это может быть объявлено другими классами. Так, можно сделать:
class Bob
{
void FuncA ()
{
Foo.Bar foobar;
}
}
Без помех, вышеупомянутому не удалось бы скомпилировать. Преимущество для этого состоит в том, что Вам не нужен новый исходный файл только для объявления интерфейса. Это также визуально связывает интерфейс Bar к классу Foo, так как необходимо записать Foo. Панель и подразумевает, что класс Foo делает что-то с экземплярами Foo. Панель.
Статичный означает, что любая часть класса пакета (проект) может получить доступ к нему, не используя указатель. Это может быть полезно или препятствовать в зависимости от ситуации.
идеальным примером usefullnes "статических" методов является Математический класс. Все методы в Математике статичны. Это означает, что Вы не должны стараться изо всех сил, сделать новый экземпляр, объявить переменные и сохранить их еще в большем количестве переменных, можно просто ввести данные и получить результат.
Статичный не всегда настолько полезно. При выполнении сравнения случая, например, Вы могли бы хотеть хранить данные несколькими различными способами. Вы не можете создать три статических метода с идентичными подписями. Вам нужны 3 различных экземпляра, нестатичные, и затем Вы можете и выдерживать сравнение, caus, если это будет статично, данные не изменятся наряду с входом.
Статические методы хороши для одноразовых возвратов и быстрых вычислений или легких полученных данных.