Dlaczego Java zabrania pól statycznych w klasach wewnętrznych?

class OuterClass {
 class InnerClass {
  static int i = 100; // compile error
  static void f() { } // compile error
 }
} 

Chociaż nie jest możliwy dostęp do pola statycznego za pomocą OuterClass.InnerClass.i, jeśli chcę zarejestrować coś, co powinno być statyczne, np. Liczbę utworzonych obiektów InnerClass, pomocne byłoby uczynienie tego pola statycznym. Dlaczego więc Java zabrania statycznych pól / metod w klasach wewnętrznych?

EDYCJA: Wiem, jak sprawić, by kompilator był zadowolony ze statycznej klasy zagnieżdżonej (lub statycznej klasy wewnętrznej), ale chcę wiedzieć, dlaczego java zabrania statycznych pól / metod wewnątrz klas wewnętrznych (lub zwykłej klasy wewnętrznej) zarówno z projektu języka, jak i aspekty wdrożeniowe, jeśli ktoś wie o tym więcej.

Ideą klas wewnętrznych jest działanie w kontekście otaczającej instancji. W jakiś sposób zezwalanie na statyczne zmienne i metody zaprzecza tej motywacji?

8.1.2 Klasy wewnętrzne i instancje zamykające

Klasa wewnętrzna jest klasą zagnieżdżoną, która nie jest jawnie ani niejawnie zadeklarowana jako statyczna. Klasy wewnętrzne nie mogą deklarować statycznych inicjatorów (§8.7) ani interfejsów składowych. Klasy wewnętrzne nie mogą deklarować statycznych elementów członkowskich, chyba że są polami stałymi czasu kompilacji (§15.28).

chcę wiedzieć, dlaczego java zabrania statycznych pól / metod wewnątrz klas wewnętrznych

Ponieważ te klasy wewnętrzne są klasami wewnętrznymi „instancji”. Oznacza to, że są one jak atrybut instancji otaczającego obiektu.

Ponieważ są to klasy „instancji”, nie ma sensu zezwalać na staticfunkcje, ponieważ staticma działać bez instancji.

To tak, jakbyś próbował jednocześnie utworzyć atrybut static / instance.

Weźmy następujący przykład:

class Employee {
    public String name;
}

Jeśli utworzysz dwie instancje pracownika:

Employee a = new Employee(); 
a.name = "Oscar";

Employee b = new Employee();
b.name = "jcyang";

Oczywiste jest, dlaczego każdy ma swoją wartość dla nieruchomości name, prawda?

To samo dzieje się z klasą wewnętrzną; każda instancja klasy wewnętrznej jest niezależna od drugiej instancji klasy wewnętrznej.

Więc jeśli spróbujesz utworzyć counteratrybut klasy, nie ma możliwości udostępnienia tej wartości w dwóch różnych instancjach.

class Employee {
    public String name;
    class InnerData {
        static count; // ??? count of which ? a or b? 
     }
}

Podczas tworzenia instancji aoraz bw powyższym przykładzie, co byłoby poprawne wartości dla zmiennej statycznej count? Nie można tego określić, ponieważ istnienie InnerDataklasy zależy całkowicie od każdego z otaczających obiektów.

Dlatego, gdy klasa jest zadeklarowana jako static, nie potrzebuje już żywej instancji, aby sama żyć. Teraz, gdy nie ma żadnej zależności, możesz swobodnie zadeklarować atrybut statyczny.

Wydaje mi się, że brzmi to powtarzalnie, ale jeśli pomyślisz o różnicach między atrybutami instancji a atrybutami klas, będzie to miało sens.

InnerClassnie może mieć staticczłonków, ponieważ należy do instancji (z OuterClass). Jeśli zadeklarujesz InnerClassjak staticodłączyć go od instancji, Twój kod zostanie skompilowany.

class OuterClass {
    static class InnerClass {
        static int i = 100; // no compile error
        static void f() { } // no compile error
    }
}

BTW: nadal będziesz mógł tworzyć wystąpienia InnerClass. staticw tym kontekście pozwala na to bez otaczającej instancji OuterClass.

W rzeczywistości możesz zadeklarować pola statyczne, jeśli są stałymi i zostały zapisane w czasie kompilacji.

class OuterClass {
    void foo() {
        class Inner{
            static final int a = 5; // fine
            static final String s = "hello"; // fine
            static final Object o = new Object(); // compile error, because cannot be written during compilation
        }
    }
}

1. class Sekwencja inicjalizacji jest krytycznym powodem.

Ponieważ klasy wewnętrzne są zależne od wystąpienia klasy otaczającej / Outer, dlatego klasa Outer musi zostać zainicjowana przed inicjalizacją klasy Inner.
To jest JLS mówi o inicjalizacji klas. Chodzi nam o to, że klasa T zostanie zainicjowana, jeśli

• Używane jest pole statyczne zadeklarowane przez T, a pole to nie jest zmienną stałą.

Więc jeśli klasa wewnętrzna ma dostęp do pola statycznego, co spowoduje zainicjowanie klasy wewnętrznej, ale nie zapewni, że klasa otaczająca zostanie zainicjowana.

2. Naruszyłoby to kilka podstawowych zasad . możesz przejść do ostatniej sekcji (do two cases), aby uniknąć rzeczy noobów

Jedną z rzeczy jest to , że gdy niektórzy będą zachowywać się tak jak normalna klasa pod każdym względem i jest to związane z klasą Outer.static nested classnested classstatic

Ale pojęcie Inner class/ czy to będzie związane z klasą zewnętrzną / otaczającą. Uwaga związana z instancją, a nie klasą. Teraz skojarzenie z instancją wyraźnie oznacza, że ​​( z koncepcji zmiennej instancji ) będzie istnieć wewnątrz instancji i będzie się różnić między instancjami. non-static nested classinstance

Teraz, kiedy zrobimy coś statycznego, spodziewamy się, że zostanie on zainicjowany podczas ładowania klasy i powinien być udostępniony wszystkim instancjom. Ale ze względu na to, że są niestatyczne, nawet same klasy wewnętrzne (na razie możesz zdecydowanie zapomnieć o wystąpieniu klasy wewnętrznej ) nie są współdzielone z wszystkimi wystąpieniami klasy zewnętrznej / otaczającej ( przynajmniej koncepcyjnie ), więc jak możemy się spodziewać, że jakaś zmienna klasy wewnętrznej zostaną podzielone między wszystkie wystąpienia klasy wewnętrznej.

Więc jeśli Java pozwala nam używać statycznej zmiennej wewnątrz nie statycznej klasy zagnieżdżonej. będą dwa przypadki .

• Jeśli jest współdzielony ze wszystkimi instancjami klasy wewnętrznej, naruszy to pojęcie context of instance(zmienna instancji). W takim razie NIE.
• Jeśli nie zostanie udostępniony wszystkim instancjom, narusza koncepcję statyczności. Znowu NIE.

Oto motywacja, którą uważam za najbardziej odpowiednią dla tego „ograniczenia”: Możesz zaimplementować zachowanie statycznego pola klasy wewnętrznej jako pole instancji obiektu zewnętrznego; Więc nie trzeba statycznych pól / metod . Chodzi mi o to, że wszystkie instancje klasy wewnętrznej jakiegoś obiektu współużytkują pole (lub metodę).

Więc załóżmy, że chcesz policzyć wszystkie instancje klasy wewnętrznej, zrobiłbyś:

public class Outer{
    int nofInner; //this will count the inner class 
                  //instances of this (Outer)object
                  //(you know, they "belong" to an object)
    static int totalNofInner; //this will count all 
                              //inner class instances of all Outer objects
    class Inner {
        public Inner(){
            nofInner++;
            totalNofInner++;
        }
    }
}

W prostych słowach, niestatyczne klasy wewnętrzne są zmiennymi instancji dla klasy zewnętrznej i są tworzone tylko wtedy, gdy tworzona jest klasa zewnętrzna, a obiekt klasy zewnętrznej jest tworzony w czasie wykonywania, podczas gdy zmienne statyczne są tworzone w czasie ładowania klasy. Tak więc niestatyczna klasa wewnętrzna jest elementem środowiska uruchomieniowego, dlatego statyczna nie jest częścią niestatycznej klasy wewnętrznej.

UWAGA: traktuj klasy wewnętrzne zawsze jak zmienną dla klasy zewnętrznej, mogą one być statyczne lub niestatyczne, jak wszystkie inne zmienne.

Ponieważ spowodowałoby to niejednoznaczność w znaczeniu „statyczności”.

Klasy wewnętrzne nie mogą deklarować statycznych elementów członkowskich innych niż stałe czasu kompilacji. Byłaby dwuznaczność co do znaczenia słowa „statyczny”. Czy to oznacza, że ​​w maszynie wirtualnej jest tylko jedno wystąpienie? Czy tylko jedna instancja na obiekt zewnętrzny? Projektanci języka postanowili nie zajmować się tym problemem.

Zaczerpnięte z „Core Java SE 9 for the Impatient” autorstwa Cay S. Horstmanna. Str. 90 Rozdział 2.6.3

Myślę, że to dla spójności. Chociaż wydaje się, że nie ma dla niego żadnych ograniczeń technicznych, nie byłbyś w stanie uzyskać dostępu do statycznych elementów klasy wewnętrznej z zewnątrz, tj. OuterClass.InnerClass.iPonieważ środkowy krok nie jest statyczny.