Анонимный по сравнению с именованными внутренними классами? - лучшие практики?

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

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

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

Я думаю, что это - вопрос вкуса. Я предпочитаю использовать анонимные классы для Функторов. Но в Вашем случае, я использовал бы внутренний класс, так как я думаю, что Вы будете упаковывать больше, чем всего несколько строк кода там, возможно, больше, чем просто метод. И это подчеркнуло бы то, что это добавляет функциональность к суперклассу путем помещения его в классе, а не скрытый где-нибудь в методе. Плюс, кто знает, возможно, когда-нибудь, Вам еще, возможно, понадобился бы подкласс где. Это, конечно, зависит от того, сколько Вы знаете о том, как Ваше программное обеспечение разовьется. Кроме этого, просто бросьте монетку.:)

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

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

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

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

Нестатические внутренние классы могут быть проблемой. Например, у нас недавно был внутренний сериализируемый класс, но внешний класс не был serializeable. Скрытая ссылка означала, что внешний класс будет также сериализирован, который, конечно, перестал работать, но это требовало времени для обнаружения почему.

Где я работаю, статические внутренние классы поощряются в наших лучших практиках кодирования (где возможный), поскольку они несут менее скрытый багаж и более минимизированы.

Анонимные внутренние классы трудно отладить в Eclipse (thats, что я использую). Вы не сможете посмотреть на переменную, оценивает/вводит значения путем простого щелчка правой кнопкой.

Сделайте самую простую вещь, которая могла возможно работать: Используйте анонимный внутренний класс.

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

(Вы сделали бы то же с переменными - помещение их в самом определенном объеме. Имеет смысл делать то же с другими исходными активами.)

Почему необходимо разделить его на подклассы? Если это должно только переопределить существующий виртуальный метод, я думаю, что анонимный внутренний класс хорошо. Если бы Вы добавляете дополнительную функциональность, я использовал бы именованный класс. Я сделал бы это вложенным классом хотя (т.е. с static модификатор) - я нахожу их легче рассуждать о :)

(Счетчик указывает Daniel Lew),

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

Кроме того, использование анонимного внутреннего класса дает любому читающему Ваш код более трудное время, поскольку они затем должны проанализировать этот класс, который появился откуда ни возьмись. Используя именованный внутренний класс Вы можете организовать источник больше.

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

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

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

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

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

Мое личное эмпирическое правило: если анонимный внутренний класс будет небольшим, придерживайтесь анонимного класса. Маленький - это примерно 20–30 строк или меньше. Если он будет длиннее, на мой взгляд, он станет нечитаемым, поэтому я делаю его именованным внутренним классом. Я помню, как однажды видел анонимный внутренний класс из 4000+ строк.