Dlaczego wszystkie pola w interfejsie są domyślnie statyczne i ostateczne?

POWÓD BYCIA final

Dowolne implementacje mogą zmieniać wartość pól, jeśli nie są definiowane jako końcowe. Wtedy staną się częścią realizacji. Interfejs jest czystą specyfikacją bez żadnej implementacji.

POWÓD BYCIA static

Jeśli są statyczne, To należą do interfejsu, a nie do obiektu, ani do typu run-time obiektu.

Jest tu kilka punktów:

To, że pola w interfejsie są domyślnie statyczne, nie oznacza, że muszą być stałymi w czasie kompilacji, a nawet niezmiennymi. Można zdefiniować np.

interface I {
  String TOKEN = SomeOtherClass.heavyComputation();
  JButton BAD_IDEA = new JButton("hello");
}

(uważaj, że robienie tego wewnątrz definicji adnotacji może mylić javac , odnosząc się do faktu, że powyższe kompiluje się do statycznego inicjalizatora.)

Również powód tego ograniczenia jest bardziej stylistyczny niż techniczny, i wiele osób chciałoby zobaczyć, jak jest zrelaksowany.

Pola muszą być statyczne, ponieważ nie mogą być abstrakcyjne (jak metody mogą). Ponieważ nie mogą być abstrakcyjne, implementatorzy nie będą w stanie logicznie dostarczyć różnych implementacji pól.

Pola muszą być ostateczne, myślę, ponieważ pola mogą być dostępne przez wiele różnych implementatorów, co pozwala na ich zmianę może być problematyczne (jako synchronizacja). Również w celu uniknięcia jego ponownego wdrożenia (ukrytego).

Tylko moja myśl.

Uważam wymóg, aby pola były ostateczne za zbyt restrykcyjne i błąd projektantów języka Java. Są czasy, np. obsługa drzewa, kiedy trzeba ustawić stałe w implementacji, które są wymagane do wykonywania operacji na obiekcie typu interface. Wybranie ścieżki kodu w klasie implementującej jest kludge. Obejście, którego używam, polega na zdefiniowaniu funkcji interfejsu i zaimplementowaniu jej poprzez zwrócenie dosłownego:

public interface iMine {
    String __ImplementationConstant();
    ...
}

public class AClass implements iMine {
    public String __ImplementationConstant(){
        return "AClass value for the Implementation Constant";
    }
    ...
}

public class BClass implements iMine {
    public String __ImplementationConstant(){
        return "BClass value for the Implementation Constant";
    }
    ...
}

Jednak byłoby prostsze, jaśniejsze i mniej podatne na błędne implementacje użycie tej składni:

public interface iMine {
    String __ImplementationConstant;
    ...
}

public class AClass implements iMine {
    public static String __ImplementationConstant =
        "AClass value for the Implementation Constant";
    ...
}

public class BClass implements iMine {
    public static String __ImplementationConstant =
        "BClass value for the Implementation Constant";
    ...
}

Specyfikacja, umowy... Instrukcja maszynowa dostępu do pola wykorzystuje adres obiektu plus przesunięcie pola. Ponieważ klasy mogą zaimplementować wiele interfejsów, nie ma sposobu, aby niekończące się pole interfejsu miało takie samo przesunięcie we wszystkich klasach rozszerzających ten interfejs. Dlatego należy zaimplementować inny mechanizm dostępu do pola: dwa dostępy do pamięci (get field offset, get field value) zamiast jednego Plus utrzymanie rodzaju wirtualnej tabeli pól (analog wirtualnej tabeli metod). Domyślam się, że po prostu nie chcieli komplikować jvm dla funkcjonalności, które można łatwo symulować za pomocą istniejących rzeczy (metod).

W Scali możemy mieć pola w interfejsach, choć wewnętrznie są one zaimplementowane tak jak wyjaśniłem powyżej (jako metody).

static:

Cokolwiek (zmienna lub Metoda), które jest static w Javie, może być wywołane jako Classname.variablename lub Classname.methodname lub bezpośrednio. Nie jest obowiązkowe wywoływanie go tylko przez użycie nazwy obiektu.

W interfejsie obiekty nie mogą być deklarowane, a static umożliwia wywoływanie zmiennych tylko poprzez nazwę klasy bez potrzeby używania nazwy obiektu.

final:

Pomaga utrzymać stałą wartość zmiennej, ponieważ nie może być nadpisana w jej podklasach.