Нет, намного.
Кроме необходимости писать метод типа fireXXXX(...) на каждый метод интерфейса слушателя, данный кусок кода не решает, например, вопросов циклического вызова слушателей или защиты механизма оповещения от плохо написанных слушателей. Добавьте эти проверки в метод fireEvent(Event), представьте что слушатель подразумевает десяток событий, а observable-объектов у вас тоже пара десятков. Вот и получите тонны одинакового кода.
А зачем использовать типизированные поля, если можно объявить их как Object?
Модификатор final в объявлении полей (пусть даже и в private классе) используется для указания того, что их значение не должно изменяться — по-моему, вполне нормальная причина.
Для методов final используется чтобы избежать их переопределения в дочерних классах, т.е. в случае, если сам класс объявлен как final или private, то final-методы в нем смысла не имеют (но у меня их и нет).
И вообще, не надо меня обвинять в бесконтрольном использовании final. Все случаи применения final в коде статьи, на мой взгляд, оправданы, а если вам так не кажется — укажите конкретное место в коде. А то заявления типа «от final рябит в глазах» или «загадить финалом сигнатуры методов» не похожи на конструктивную критику. :)
Во-первых, никто не говорил про использование final «где ни попадя».
Во-вторых, приведенная статья сводится к мысли «не используйте final без причины, а причину документируйте». Полностью поддерживаю такую позицию. Соглашусь, что в приведенном в статье коде нет JavaDoc'ов, но это было сделано с умыслом, дабы не отвлекать читателя от основной идеи.
Не вижу принципиальных противоречий со статьей. Поясните пожалуйста мысль, если не сложно.
От себя: считаю, что нет никакого криминала в отлове Exception или даже Throwable при определенных обстоятельствах, и, применительно к статье, эти обстоятельства имеют место
Наследство C++ у меня и вправду есть, но вовсе не такое тяжелое :)
Что же касается подчеркивания, то оно с успехом применяется и в Java (также как и другие префиксы декларированных полей, типа m_ или f_), причем не противоречит code conventions. Подчеркивание в середине идентификатора — это действительно немного не по-java'овски, но это уж мой личный каприз :) Надеюсь, он не помешал восприятию идеи.
А final — это хорошо везде, где не бессмысленно.
В моем приложении разработчикам было настоятельно рекомендовано реализовывать подписчики так, чтобы они вообще не выбрасывали исключений, а обрабатывали бы их сами. Это и логично, т.к. подписчик — это по сути автономная подпрограмма. Тому, кто его вызывает, о нем ничего неизвестно и, следовательно, вызывающей стороне глубоко наплевать какие он там исключения генерит или нет (вызывающая сторона чаще всего и не может их обработать, ее дело — только вызвать).
Поэтому здесь отлов Throwable с записью в лог — это «последний барьер защиты» и по-хорошему, конечно, до него дойти не должно.
Насчет 1 и 2 — да, вы правы, спасибо за замечание. Что касается _current_events, то его, вероятно, следует сделать ThreadLocal.
Относительно эе отлова Throwable я не согласен. Тут дело не в стиле программирования, а в логике оповещения подписчиков. Ведь подписчики ничего не знают друг о друге, почему же одни должны «страдать» от кривости других, только потому что они подписались на данное событие позже?
К слову сказать, в процессе написания ListenerInvocationHandler, именно из-за соображений типа п. 3, одно время слушатели из списка вызывались каждый в отдельном потоке. Но на практике это оказалось совершенно crazy, поэтому вернулись к варианту с подавлением исключений.
Можно, конечно, спорить, что лучше ловить — Throwable или Exception, но это в данном случае скорее дело вкуса, чем вопрос по существу.
JavaDoc особо эту тему не комментирует, но, судя по тому, что существует Thread.setContextClassLoader(ClassLoader), видимо, можно явно выставить загрузчик текущего контеста в null.
Недолгое гугление навело на информацию о том, что (http://stackoverflow.com/questions/225594/thread-getcontextclassloader-null)
Java threads created from JNI code in a non-java thread have null ContextClassloader unless the creator explicitly sets it.
Also in such context Thread.currentThread() returns null.
Т.е. строго говоря, при некоторых обстоятельствах, не только getContextClassLoader(), но даже Thread.currentThread() может вернуть null.
Полагаю, что программы, рассчитанные на работу в условиях, где подобное возможно, должны предусмотреть собственный метод типа getCurrentValidClassLoader(), в котором аккуратно
обрабатывать все возможные нюансы. В этой же статье добавление подобного обработчика просто
собьет читателей с толку.
С точки зрения чистой модели — действительно, никакой разницы. Но я говорил не о модели только, но преимущественно — о процессах мышления, осмысления и обсуждения, связанных с этой моделью. А здесь, как мне кажется, разница есть.
Но в целом я согласен, по большому счету это лишь вопрос вкуса и привычки :)
Не знаю как у кого, но у меня эта привычка развилась от нежелания смешивать классы и интерфейсы на уровне модели. Дело в том, что модель — она не только в IDE, она еще и в CASE-средствах, на бумаге, в голове, но главное — в разговорах.
Здесь подобная «вербальная семантика» бывает очень полезна (по крайней мере, по моему опыту)
Кроме необходимости писать метод типа fireXXXX(...) на каждый метод интерфейса слушателя, данный кусок кода не решает, например, вопросов циклического вызова слушателей или защиты механизма оповещения от плохо написанных слушателей. Добавьте эти проверки в метод fireEvent(Event), представьте что слушатель подразумевает десяток событий, а observable-объектов у вас тоже пара десятков. Вот и получите тонны одинакового кода.
Модификатор final в объявлении полей (пусть даже и в private классе) используется для указания того, что их значение не должно изменяться — по-моему, вполне нормальная причина.
Для методов final используется чтобы избежать их переопределения в дочерних классах, т.е. в случае, если сам класс объявлен как final или private, то final-методы в нем смысла не имеют (но у меня их и нет).
И вообще, не надо меня обвинять в бесконтрольном использовании final. Все случаи применения final в коде статьи, на мой взгляд, оправданы, а если вам так не кажется — укажите конкретное место в коде. А то заявления типа «от final рябит в глазах» или «загадить финалом сигнатуры методов» не похожи на конструктивную критику. :)
Во-вторых, приведенная статья сводится к мысли «не используйте final без причины, а причину документируйте». Полностью поддерживаю такую позицию. Соглашусь, что в приведенном в статье коде нет JavaDoc'ов, но это было сделано с умыслом, дабы не отвлекать читателя от основной идеи.
От себя: считаю, что нет никакого криминала в отлове Exception или даже Throwable при определенных обстоятельствах, и, применительно к статье, эти обстоятельства имеют место
Что же касается подчеркивания, то оно с успехом применяется и в Java (также как и другие префиксы декларированных полей, типа m_ или f_), причем не противоречит code conventions. Подчеркивание в середине идентификатора — это действительно немного не по-java'овски, но это уж мой личный каприз :) Надеюсь, он не помешал восприятию идеи.
А final — это хорошо везде, где не бессмысленно.
Поэтому здесь отлов Throwable с записью в лог — это «последний барьер защиты» и по-хорошему, конечно, до него дойти не должно.
Относительно эе отлова Throwable я не согласен. Тут дело не в стиле программирования, а в логике оповещения подписчиков. Ведь подписчики ничего не знают друг о друге, почему же одни должны «страдать» от кривости других, только потому что они подписались на данное событие позже?
К слову сказать, в процессе написания ListenerInvocationHandler, именно из-за соображений типа п. 3, одно время слушатели из списка вызывались каждый в отдельном потоке. Но на практике это оказалось совершенно crazy, поэтому вернулись к варианту с подавлением исключений.
Можно, конечно, спорить, что лучше ловить — Throwable или Exception, но это в данном случае скорее дело вкуса, чем вопрос по существу.
JavaDoc особо эту тему не комментирует, но, судя по тому, что существует Thread.setContextClassLoader(ClassLoader), видимо, можно явно выставить загрузчик текущего контеста в null.
Недолгое гугление навело на информацию о том, что (http://stackoverflow.com/questions/225594/thread-getcontextclassloader-null)
Т.е. строго говоря, при некоторых обстоятельствах, не только getContextClassLoader(), но даже Thread.currentThread() может вернуть null.
Полагаю, что программы, рассчитанные на работу в условиях, где подобное возможно, должны предусмотреть собственный метод типа getCurrentValidClassLoader(), в котором аккуратно
обрабатывать все возможные нюансы. В этой же статье добавление подобного обработчика просто
собьет читателей с толку.
Но за замечание все равно спасибо.
Но в целом я согласен, по большому счету это лишь вопрос вкуса и привычки :)
Здесь подобная «вербальная семантика» бывает очень полезна (по крайней мере, по моему опыту)