Почему у нас не может быть статического метода в (нестатическом) внутреннем классе?

Внутренний класс полностью отличается от статического вложенного класса, хотя оба они похожи по синтаксису. Статические вложенные классы - это только средство для группировки, тогда как внутренние классы имеют сильную ассоциацию и доступ ко всем значениям своего внешнего класса. Вы должны быть уверены, почему вы хотите использовать внутренний класс, и тогда должно быть довольно естественно, какой из них вы должны использовать. Если вам нужно объявить статический метод, вероятно, вам все равно понадобится статический вложенный класс.

Вам разрешены статические методы для статических вложенных классов. Например

public class Outer {

  public static class Inner {

    public static void method() {

    }
  }
}

У меня есть теория, которая может быть верной, а может и нет.

Во-первых, вы должны знать некоторые вещи о том, как внутренние классы реализованы в Java. Предположим, у вас есть этот класс:

class Outer {
    private int foo = 0;
    class Inner implements Runnable {
        public void run(){ foo++; }
    }
    public Runnable newFooIncrementer(){ return new Inner(); }
}

Когда вы его компилируете, сгенерированный байт-код будет выглядеть так, как если бы вы написали что-то вроде этого:

class Outer {
    private int foo = 0;
    static class Inner implements Runnable {
        private final Outer this$0;
        public Inner(Outer outer){
            this$0 = outer;
        }
        public void run(){ this$0.foo++; }
    }
    public Runnable newFooIncrementer(){ return new Inner(this); }
}

Теперь, если мы разрешили статические методы в нестатических внутренних классах, вам может потребоваться сделать что-то вроде этого.

class Outer {
    private int foo = 0;
    class Inner {
        public static void incrFoo(){ foo++; }
    }
}

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

class Outer {
    private int foo = 0;
    static class Inner {
        private final Outer this$0;
        public Inner(Outer outer){
            this$0 = outer;
        }
        public static void incrFoo(){ this$0.foo++; }
    }
}

... что явно не будет работать, поскольку этот $ 0 нестатичен. Это объясняет, почему статические методы не разрешены (хотя вы можете указать, что вы можете разрешить статические методы, если они не ссылаются на включающий объект), и почему у вас не может быть неокончательных статических полей ( было бы нелогично, если бы экземпляры нестатических внутренних классов из разных объектов разделяли «статическое состояние»). Это также объясняет, почему поля final разрешены (пока они не ссылаются на включающий объект).

Нет особого смысла разрешать статический метод в нестатическом внутреннем классе; как бы вы получили к нему доступ? Вы не можете получить доступ (по крайней мере, изначально) к нестатическому экземпляру внутреннего класса, не пройдя через экземпляр внешнего класса. Не существует чисто статического способа создания нестатического внутреннего класса.

Для внешнего класса Outer вы можете получить доступ к статическому методу test () следующим образом:

Outer.test();

] Для статического внутреннего класса Inner вы можете получить доступ к его статическому методу innerTest () следующим образом:

Outer.Inner.innerTest();

Однако, если Inner не является статическим, существует теперь нет чисто статического способа ссылки на метод innertest . Нестатические внутренние классы привязаны к конкретному экземпляру своего внешнего класса. Функция отличается от константы, в том, что ссылка на Outer.Inner.CONSTANT гарантированно будет однозначной, в отличие от вызова функции Outer.Inner.staticFunction (); - нет. Допустим, у вас есть Inner.staticFunction () , которая вызывает getState () , который определен в Outer . Если вы попытаетесь вызвать эту статическую функцию, у вас появится неоднозначная ссылка на внутренний класс. То есть в каком экземпляре внутреннего класса вы вызываете статическую функцию? Это имеет значение. Видите ли, нет действительно статического способа ссылаться на этот статический метод из-за неявной ссылки на внешний объект.

Пол Беллора прав, что разработчики языка могли это допустить. Затем им придется тщательно запретить любой доступ к неявной ссылке на внешний класс в статических методах нестатического внутреннего класса. На данный момент, каково значение этого внутреннего класса, если вы не можете ссылаться на внешний класс, кроме как статически? И если статический доступ в порядке, то почему бы не объявить весь внутренний класс статическим? Если вы просто сделаете сам внутренний класс статическим, у вас не будет неявной ссылки на внешний класс, и у вас больше не будет этой двусмысленности.

Если вам действительно нужны статические методы для нестатического внутреннего класса class, то вам, вероятно, нужно пересмотреть свой дизайн.

тогда почему бы не объявить весь внутренний класс статическим? Если вы просто сделаете сам внутренний класс статическим, у вас не будет неявной ссылки на внешний класс, и у вас больше не будет этой двусмысленности.

Если вам действительно нужны статические методы для нестатического внутреннего класса class, то вам, вероятно, нужно пересмотреть свой дизайн.

тогда почему бы не объявить весь внутренний класс статическим? Если вы просто сделаете сам внутренний класс статическим, у вас не будет неявной ссылки на внешний класс, и у вас больше не будет этой двусмысленности.

Если вам действительно нужны статические методы для нестатического внутреннего класса class, то вам, вероятно, нужно пересмотреть свой дизайн.

предположим, что существует два экземпляра внешнего класса, и оба они имеют экземпляр внутреннего класса. Теперь, если внутренний класс имеет один статический член, он будет хранить только одну копию этого члена в области кучи. В этом случае оба объекта внешнего класса будут относятся к этой единственной копии, и они могут изменить ее вместе. Это может вызвать ситуацию "грязного чтения", следовательно, чтобы предотвратить это, Java применила это ограничение. Другой сильной стороной для поддержки этого аргумента является то, что java разрешает здесь final статические члены, значения которых могут не может быть изменен ни с одним из объектов внешнего класса. Пожалуйста, позвольте мне, если я ошибаюсь.