Совершенно с вами согласен. Из-за этого пример ещё более синтетически выглядит чем мог быть. Глаз за класс Counter цепляется сразу и хочется его банально удалить :)
Да ладно вам, нормальное такое лицо. Просто фотография неудачная, мне кажется. У него вполне разумный взгляд. Вот в мою школьную молодость гопника можно было сразу отличить по абсолютно бесмысленно-тупому взгляду.
Мне кажется, что слова «Их несколько» смотрятся очень нелогично там. Есть предложение поменять на «Причин несколько». Спасибо за статью, просто резануло глаз.
Очень печально, что Вы не видите разницу между явно написанным кодом и неявно.
PS: Ещё один момент: нормальное IDE (вроде Eclips'а), для джавы, даст вам в один щелчок перейти к телу «writeForMethod», а вот определение @Loggable хоть и откроется, но читабельность его будет ниже (пойди ещё разбери чего там в классе нафигачили).
В общем, если вам нравится — пользуйте, конечно, но крайне рекомендую ознакомиться и с точкой зрения противников метода. Вы правильно говорите, иногда за деревьями не видно леса. Вот AOP зачастую бывает теми деревьями. Как правило всегда можно проще и читабельнее…
Когда метод что-то использует, он делает это ЯВНО, вызывая что-то ЯВНО. (Ну или как там правильно говорить, посылая сообщения ;)). В случае же с AOP в методе НЕТ явного обращения к кэшу, или логгирования (ну или ещё какой хитрой логики). Оно происходит «за сценой», скрыто от вас при прочтении. Это, намой взгляд, ужасный недостаток. ДАЖЕ с аннотациями (которые какбэ намекают, ага).
Ну а насчёт xml… Это как раз spring-way (по крайней мере был раньше). Автор в статье как раз про него и говорит в конце…
Не могу сказать что являюсь противником или последователем данной технологии. У всего есть свои плюсы и минусы. Но недолюбливаю AOP за его «скрытность». Когда читаешь метод, должно быть понятно что он делает. И довольно неприятно каждый раз, натыкаясь на аннотацию AOP вспоминать что этот метод может НЕЯВНО (в коде то в методе этого НЕТ) делать ещё что-то. И это скажите спасибо если метод аннотирован, а если используется любимое spring-way-xml-programming, то всё — тушите свет. Что на самом деле делает код, можно понять только после поллитры. =\
PS: Мнение рождено не на пустом месте. Пришлось пару лет поработать на проекте, где кэшинг (и ещё что-то, уже не помню что) активно прикручивали на Аспектах. Не могу сказать чтобы код блистал понятностью своей.
PPS: А за статью спасибо, конечно, она довольно понятно всё объясняет. Только вот определения Аспекта и Совета выглядят (для меня по крайней мере) весьма размыто.
За статью спасибо. Хотя мне кажется, что пункты 1 и 2 надо местами поменять :) Вопрос «Зачем» и правда зачастую помогает тут же понять, что дальше двигаться и не нужно :)
PS: Ещё один момент: нормальное IDE (вроде Eclips'а), для джавы, даст вам в один щелчок перейти к телу «writeForMethod», а вот определение @Loggable хоть и откроется, но читабельность его будет ниже (пойди ещё разбери чего там в классе нафигачили).
В общем, если вам нравится — пользуйте, конечно, но крайне рекомендую ознакомиться и с точкой зрения противников метода. Вы правильно говорите, иногда за деревьями не видно леса. Вот AOP зачастую бывает теми деревьями. Как правило всегда можно проще и читабельнее…
В целом, если построено на аннотациях, должно по идее работать нормально.
Когда метод что-то использует, он делает это ЯВНО, вызывая что-то ЯВНО. (Ну или как там правильно говорить, посылая сообщения ;)). В случае же с AOP в методе НЕТ явного обращения к кэшу, или логгирования (ну или ещё какой хитрой логики). Оно происходит «за сценой», скрыто от вас при прочтении. Это, намой взгляд, ужасный недостаток. ДАЖЕ с аннотациями (которые какбэ намекают, ага).
Ну а насчёт xml… Это как раз spring-way (по крайней мере был раньше). Автор в статье как раз про него и говорит в конце…
PS: Мнение рождено не на пустом месте. Пришлось пару лет поработать на проекте, где кэшинг (и ещё что-то, уже не помню что) активно прикручивали на Аспектах. Не могу сказать чтобы код блистал понятностью своей.
PPS: А за статью спасибо, конечно, она довольно понятно всё объясняет. Только вот определения Аспекта и Совета выглядят (для меня по крайней мере) весьма размыто.
И не бередите рану, а то я ещё начну Джавовские перлы выкладывать. Знаете, тоже накопилось воз и тележка ;)