Чому Java забороняє статичні поля у внутрішніх класах?

Question 1

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

Хоча неможливо отримати доступ до статичного поля за допомогою OuterClass.InnerClass.i, якщо я хочу записати щось, що повинно бути статичним, наприклад, кількість створених об'єктів InnerClass, було б корисно зробити це поле статичним. То чому Java забороняє статичні поля / методи у внутрішніх класах?

EDIT: Я знаю, як зробити компілятор задоволеним статичним вкладеним класом (або статичним внутрішнім класом), але те, що я хочу знати, - це те, чому java забороняє статичні поля / методи всередині внутрішніх класів (або звичайний внутрішній клас) як з мовного дизайну, так і з аспекти реалізації, якщо хтось знає про це більше.

Question 2

Ідея внутрішніх класів полягає в тому, щоб діяти в контексті екземпляра, що вкладається. Якось, дозволяючи статичні змінні та методи суперечить цій мотивації?

8.1.2 Внутрішні класи та огороджувальні екземпляри

Внутрішній клас - це вкладений клас, який явно або неявно не оголошений статичним. Внутрішні класи не можуть оголошувати статичні ініціалізатори (§8.7) або інтерфейси-члени. Внутрішні класи не можуть оголошувати статичні члени, якщо вони не є полями константи часу компіляції (§15.28).

Question 3

я хочу знати, чому Java забороняє статичні поля / методи всередині внутрішніх класів

Тому що ці внутрішні класи - це "екземпляри" внутрішніх класів. Тобто вони схожі на атрибут екземпляра об’єкта, що охоплює.

Оскільки вони є "екземплярами" класів, немає сенсу дозволяти staticфункції, оскільки, staticпо-перше, передбачається робота без екземпляра.

Це все одно, що ви намагаєтесь створити статичний атрибут / екземпляр одночасно.

Візьмемо такий приклад:

class Employee {
    public String name;
}

Якщо ви створюєте два екземпляри працівника:

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

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

Зрозуміло, чому кожна з них має власну вартість власності name, так?

Те саме відбувається з внутрішнім класом; кожен екземпляр внутрішнього класу не залежить від іншого екземпляра внутрішнього класу.

Отже, якщо ви намагаєтесь створити counterатрибут класу, немає можливості поділитися цим значенням у двох різних екземплярах.

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

Коли ви створюєте примірник aта bу наведеному вище прикладі, яке буде правильним значенням для статичної змінної count? Визначити це неможливо, оскільки існування InnerDataкласу повністю залежить від кожного з об'єктів, що укладають.

Ось чому, коли клас оголошується як static, йому вже не потрібен живий екземпляр, щоб жити самим собою. Тепер, коли немає залежності, ви можете вільно оголосити статичний атрибут.

Я думаю, це звучить повторно, але якщо задуматися про різницю між атрибутами екземпляра та класу, це матиме сенс.

Question 4

InnerClassне може мати staticчленів, оскільки він належить екземпляру (з OuterClass). Якщо ви заявите InnerClass, staticщо від'єднаєте його від екземпляру, ваш код буде скомпільовано.

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

BTW: Ви все одно зможете створювати екземпляри InnerClass. staticу цьому контексті дозволяє це відбуватися без огороджувального екземпляра OuterClass.

Question 5

Насправді, ви можете оголосити статичні поля, якщо вони є константами і записані під час компіляції.

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

Question 6

Послідовність ініціалізації класу є критичною причиною.

Оскільки внутрішні класи залежать від екземпляра класу enclosing / Outer, так і Outer клас потрібно ініціалізувати перед ініціалізацією внутрішнього класу.
Це JLS говорить про ініціалізацію класу. Суть, який нам потрібен, полягає в тому, що клас T буде ініціалізований if

Використовується статичне поле, оголошене T, і поле не є постійною змінною.

Отже, якщо внутрішній клас має доступ до статичного поля, що спричинить ініціалізацію внутрішнього класу, але це не забезпечить ініціалізацію закритого класу.

Це порушило б деякі основні правила . Ви можете перейти до останнього розділу (до two cases), щоб уникнути жодної речі

Одна річ про те , коли деякі єstatic nested classnested classstatic він буде вести себе так само , як звичайний клас в усіх відношеннях , і це пов'язано із зовнішнім класом.

Але концепція Inner class/ is це буде пов'язана з класом зовнішнього / огороджувального. Зверніть увагу, пов’язане з екземпляром, а не класом. Тепер асоціювання з екземпляром однозначно означає, що ( з поняття змінної екземпляра ) воно буде існувати всередині екземпляра і буде відрізнятися між екземплярами. non-static nested classinstance

Тепер, коли ми робимо щось статичне, ми очікуємо, що воно буде ініціалізоване під час завантаження класу і має бути спільним для всіх примірників. Але оскільки вони є нестатичними, навіть самі внутрішні класи (на даний момент ви точно можете забути про екземпляр внутрішнього класу ) не діляться з усіма екземплярами зовнішнього / закриваючого класу ( принаймні концептуально ), то як можна очікувати, що якась змінна внутрішнього класу буде спільним для всіх екземплярів внутрішнього класу.

Отже, якщо Java дозволяє нам використовувати статичну змінну всередині не статичного вкладеного класу. буде дві справи .

Якщо його спільно використовувати з усіма екземплярами внутрішнього класу, це порушить концепцію context of instance(змінної екземпляра). Тоді це НІ.
Якщо його не надаватимуть всій інстанції, це порушить концепцію статичності. Знову НІ.

Question 7

Ось мотивація, яку я вважаю найбільш підходящою для цього "обмеження": Ви можете реалізувати поведінку статичного поля внутрішнього класу як поле екземпляра зовнішнього об'єкта; Отже, вам не потрібні статичні поля / методи . Я маю на увазі, що всі екземпляри внутрішнього класу якогось об’єкта мають спільне поле (або метод).

Отже, припустимо, ви хочете порахувати всі екземпляри внутрішнього класу, ви зробите:

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

Question 8

Простими словами, нестатичні внутрішні класи є змінними екземпляра для зовнішнього класу, і вони створюються лише тоді, коли створюється зовнішній клас і зовнішній об'єкт класу створюється під час виконання, тоді як статичні змінні створюються під час завантаження класу. Отже, нестатичний внутрішній клас - це середовище виконання, тому статичний не є частиною нестатичного внутрішнього класу.

ПРИМІТКА: обробляйте внутрішні класи завжди як змінні для зовнішнього класу, вони можуть бути статичними або нестатичними, як і будь-які інші змінні.

Question 9

Тому що це спричиняло б двозначність у значенні «статичний».

Внутрішні класи не можуть оголошувати статичні члени, крім констант часу компіляції. Існувала б неоднозначність щодо значення поняття "статичний". Чи означає це, що у віртуальній машині є лише один екземпляр? Або лише один екземпляр на зовнішній об’єкт? Мовні дизайнери вирішили не вирішувати цю проблему.

Взято з "Core Java SE 9 для нетерплячих" Кей С. Хорстманн. Сторінка 90 Розділ 2.6.3

Question 10

Думаю, це для послідовності. Хоча для цього, здається, немає жодних технічних обмежень, ви не зможете отримати доступ до статичних членів внутрішнього класу ззовні, тобто OuterClass.InnerClass.iтому, що середній крок не є статичним.