2015-01-15 4 views
0

В Java мы не можем объявлять статические инициализаторы или интерфейсы-члены в локальном классе (статические члены могут быть объявлены при условии, что они окончательные и могут быть инициализированы во время компиляции). Почему мой вопрос? В чем смысл этого дизайнерского решения?Почему локальные классы в java не могут объявлять статические инициализаторы и интерфейсы членов

Благодаря

+3

Под «местным классом» вы подразумеваете внутренний класс? –

+4

Я не знаю, на этот вопрос можно ответить * если только Джеймс Гослинг не прогуливается. Рассматривали ли вы просмотр байт-кода с помощью 'javap -v'? –

+0

Как мы должны знать ответ на этот вопрос? – Radiodef

ответ

1

Локальные классы могут быть доступны только внутри блока метода или объема, в котором они определены.

статический инициализатор или интерфейс не имеет смысла в этом контексте

+2

Да, но почему мой вопрос? в чем смысл? Почему это не имеет смысла? Пожалуйста, уточните пример. – BestCoderEver

1

Я думаю, что внутренние классы не являются статическими, по определению, потому что они могут получить доступ к не статическим членам класса они содержатся в.

Это означает, что любые «статические методы» этого класса будет, по сути, быть не статичным, как они могут отличаться в зависимости от того, какой объект они содержатся в

. Например:

public class Container { 
    public int x; 
    public class Contained { 
     static int x = Container.this.x; 
    } 
} 

Если скомпилирован, вы можете сделать это:

Container a = new Container(); 
a.x = 1; 
Container b = new Container(); 
b.x = 2; 

Тогда a.Contained.x != b.Contained.x (предполагается, что эта линия может компилировать), который не имеет смысла, так как оба они должны быть static.

+0

Это вряд ли является веской причиной. Статический инициализатор не может получить доступ к членам экземпляра для начала. – Radiodef

+0

О, я понимаю, что вы имеете в виду. Если статический метод не может получить доступ к методам экземпляра класса контейнера, то он в основном _is_ в статическом классе. Я думаю, что философия дизайна заключалась в том, что вы должны просто определить статический класс, если хотите этот тип поведения. –

+0

Чтобы разработать, я предположил, что вы имели в виду, что статические инициализаторы/методы могли обращаться к методам экземпляра из контейнера (поскольку класс isn ' t определяется независимо от объекта, в котором он содержится) –

0

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

1

Фактически локальные классы, если non-static, являются членами класса, который его содержит. И если сам класс non-static, его экземпляры содержатся в экземплярах класса, который его содержит (технически они ссылаются на экземпляры основного класса, которые его содержат). И поэтому наличие статических инициализаторов здесь не имеет смысла в локальном классе. Как n количество экземпляров локального класса не может делиться материалами, поскольку они всегда дискретны.

Смежные вопросы