Комментарии 26
Мы применяли AOP/AspectJ одно время. Потом отказались, т.к. он значительно увеличивает время компиляции, ну и поддержка AOP в эклипсе была реализована, скажем так, не очень. Оказалось, что писать логгирование и обработку ошибок в нужных местах вручную не так уж и сложно :-)
Интересно использование AOP вместо самодельных правил для checkstyle… Выглядит, во всяком случае, короче.
Знаете, это наверное ужаснейшая статья, которую я читал за последнее время. Где хоть какие то пояснения что происходит?
Что конкретно вызывает вопросы? Может, я помогу разобраться в комментариях? :)
ну я вообще аоп не понимал, пока не стал в тырпыпрайзе полноценном работать(не бекенд сайта)) так что имхо тут только имея опыт можно понять, а нафига оно нужно
я не андроид разработчик, но с явой я знаком весьма не плохо. Извините, но все что стоит после «О нестандартных аспектах применения аспектов.» мне абсолютно не понятно.
Эта часть описывает взаимодействия с кодом на уровне команд компилятору. Другими словами, AspectJ позволяет описывать правила вхождений/исключений каких-либо директив в java-исходниках и компилятор будет ругаться при сборке проекта, если эти правила были нарушены разработчиком :)
При этом, компилятор не просто смотрит на код, как на текст, а так же анализирует контекст класса/объекта, области видимости и вызова методов, обработку ошибок. И также позволяет настраивать порядок внедрения инъекций :)
При этом, компилятор не просто смотрит на код, как на текст, а так же анализирует контекст класса/объекта, области видимости и вызова методов, обработку ошибок. И также позволяет настраивать порядок внедрения инъекций :)
Для тех, кому лень читать или не понятны какие-либо магические штуки, о которых я рассказываю — можно послушать и посмотреть мой доклад в Яндексе на Droid Party, где я подробно рассказываю материал этой статьи :)
«И если о первых трёх технологиях слышал каждый разработчик, а многие даже применяют их у себя, то о четвёртой знают только хардкорные джависты, пишущие большие серверные проекты и разного рода энтерпрайзы.»
Это чувство, когда ты используешь AspectJ в каждом втором проекте, а о первых трех даже не слышал.
Это чувство, когда ты используешь AspectJ в каждом втором проекте, а о первых трех даже не слышал.
Я не экстрасенс — но с аоп у вас будут проблемы -сначала все ОК! Через годик пожалауйста напишите как у вас с аоп!
Это скорее проблема языка, нет никаких проблем решить те же проблемы стандартными шаблонами, но скудность синтаксиса и малая выразительность ведут к громоздкости такого кода, отсюда все это программирование на аннотациях
«Сахарные примеси аспектного подхода в (Kotlin)» — такого ругательства я еще не слышал. Ни к сахару, ни к аспектам функции-расширения Kotlin особого отношения не имеют, IMO.
Экстенды методов и полей не вставляются в целевой класс, а значит это именно «синтаксический сахар». Но они связывают код конкретного класса (и дают доступ к приватным полям/методам) и самой программы — а это аспектный подход. :)
Под «синтаксическим сахаром» обычно понимается конструкции которые дублируют что-то еще, существующее в языки и/или абстракции, которые «протекают». Функции-расширения не могут быть заменены обычными функциями (в отличие от C#) и не являются методами из-за отличающихся правил диспатча (в отличие от Swift). Это отдельная логическая сущность в Kotlin которая не может быть выражена через остальные примитивы языка.
Расширения не дают доступ к приватным членам класса из вне, пожалуйста проверь это утверждение на коде
Расширения не дают доступ к приватным членам класса из вне, пожалуйста проверь это утверждение на коде
Насчёт приватного доступа вы правы, я что-то напутал :)
Тем не менее, это синтаксический сахар в своём чистом виде — по сути, обычные статические методы, которые первым аргументом принимают целевой класс. Без статического импорта нужного метода/поля эти экстенды работать не будут и в целевом классе не появятся :)
Тем не менее, это синтаксический сахар в своём чистом виде — по сути, обычные статические методы, которые первым аргументом принимают целевой класс. Без статического импорта нужного метода/поля эти экстенды работать не будут и в целевом классе не появятся :)
Кажется мы расходимся в определении «сахара».
Замечу что если под «не сахарными» расширениями понимать например то, что есть в Swift, где расширение не сильно отличается от метода по свойствам и видно глобально, то получается забавная картина. Swift не имеет аналога Kotlin DSL ровно из-за глобальности их функций-расширений, то есть «хардкорные» фичи проигрывают «сахару» по функциональности. Постройка древовидных DSL очень важная фича Kotlin, и уж точно не является сахаром, так как обеспечивает статические гарантии структуры.
Замечу что если под «не сахарными» расширениями понимать например то, что есть в Swift, где расширение не сильно отличается от метода по свойствам и видно глобально, то получается забавная картина. Swift не имеет аналога Kotlin DSL ровно из-за глобальности их функций-расширений, то есть «хардкорные» фичи проигрывают «сахару» по функциональности. Постройка древовидных DSL очень важная фича Kotlin, и уж точно не является сахаром, так как обеспечивает статические гарантии структуры.
Скажите пожалуйста, насколько я понимаю, оверхеда в райнтайме нет? У нас просто генерируется дополнительный байт код во время компиляции?
Именно. Однако, некоторые инструкции генерируют рантайм-проверки, избыток и нагруженность которых может значительно замедлять работу программы.
Я так понимаю речь идет о not-null ассертах. Кто-то замерял на сколько замедляется выполнение программы с ними? JIT вполне способен убрать лишние проверки из исполнения, если например они дублируют друг друга. К тому же если я правильно понимаю как JVM оптимизации работают, код с проверками может работать быстрее так как JVM не нужно эмулировать NPE в случае нулевых ссылок.
NonNull-проверки действительно очень быстро работают и не замедляют основное выполнение. Я имел в виду более сложные вещи: директивы cflow/cflowbelow и динамическая директива if(expr), которая в рантайме выполняется на каждом джоинпоинте.
Но можно выстрелить в ногу еще более изощрённо. Например, написать срез, в область видимости которого попадает каждый метод каждого класса и уже внутри джоинпоинтов выполняются runtime-проверки на наличие аннотаций над методами. В таком сценарии время выполнения методов будет сильно провисать.
К слову, на последних версиях андроида уже нет JIT'a. Среда выполнения ART прекомпилирует код приложения при установке и, поэтому, никаких дополнительных оптимизаций уже не будет в процессе выполнения.
Но можно выстрелить в ногу еще более изощрённо. Например, написать срез, в область видимости которого попадает каждый метод каждого класса и уже внутри джоинпоинтов выполняются runtime-проверки на наличие аннотаций над методами. В таком сценарии время выполнения методов будет сильно провисать.
К слову, на последних версиях андроида уже нет JIT'a. Среда выполнения ART прекомпилирует код приложения при установке и, поэтому, никаких дополнительных оптимизаций уже не будет в процессе выполнения.
а можно сконфигурировать компилятор aspectJ, чтобы эти проверки не добавлялись?
Нельзя, т.к. некоторые директивы напрямую вносят эти проверки. Но можно написать срезы, которые не порождают эти проверки :) В основном, проверки вставляются туда, где нет возможность статически выявить типы и приходится эту функцию переносить в рантайм. Например, проверки аннотаций над аргументами/методом/классом чаще всего разрешаются в рантайме, если описывать их в срезе. Это можно обойти, если использовать механизмы маркировки и расширения дерева родителей класса.
RxJava, Dagger 2, Retrolambda и AspectJ. И если о первых трёх технологиях слышал каждый разработчик, а многие даже применяют их у себя, то о четвёртой знают только хардкорные джавистыэто только у меня с точностью до наоборот? RxJava правда еще немного читал, но Dagger 2, Retrolambda — ни разу нигде не встречал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Теория и практика AOP. Как мы это делаем в Яндексе