Ассемблерные атрибуты многоадресной рассылки. Они злы?

Question

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

[assembly: Repeatable(
AspectPriority = 2, 
AttributeTargetAssemblies = "MyNamespace", 
AttributeTargetTypes = "MyNamespace.MyClass", 
AttributeTargetMemberAttributes = MulticastAttributes.Public, 
AttributeTargetMembers = "*Impl", Prefix = "Cls")] 

Что мне не нравится об этом, в том, что она ставит часть логики в AssemblyInfo (Info, заметьте!), Что для начала не должен содержать никакой логики вообще. Хуже всего то, что MyClass.cs не имеет атрибута в любом месте файла, и совершенно неясно, что методы этого класса могут иметь их. С моей точки зрения, это сильно ухудшает читаемость кода (не говоря уже о том, что чрезмерное использование PostSharp может привести к отладке кошмара). Особенно если у вас есть несколько атрибутов многоадресной передачи.

Какова наилучшая практика здесь? Кто-нибудь там использует атрибуты PostSharp, как это?

Answer 1

Позвольте мне сначала ответить Макс: действительно, аспекты не являются альтернативой хорошим образцом ООП. Они являются дополнением. Любой хороший дизайн АОП начинается с хорошего дизайна ООП. Но шаблоны ООП иногда заставляют вас писать много сантехники вручную. Для этих случаев аспекты могут быть использованы для автоматизировать внедрение рисунка ООП, не для их замены.

Когда вы используете AOP разумно, ваше решение может быть понятнее (бизнес-код не смешивается с кодом обслуживания), чтобы проверить (вы можете протестировать аспект независимо от бизнес-кода, то есть вам не нужно проверять, что любой бизнес-метод правильно отслеживает), изменить (вам просто нужно изменить аспект, когда вы хотите изменить шаблон, вместо изменения каждой реализации шаблона).Теперь, если вы злоупотребляете AOP, если вы используете его как инструмент взлома, если раньше вы не думали о шаблонах ООП, тогда вы получите больше затрат, чем выгоды от АОП. Как любой резкий инструмент, АОП следует использовать разумно.

Назад к исходному вопросу.

Кто скажет, что вы должны указывать аспекты в AssemblyInfo.cs? Вы можете создать новый файл GlobalAspects.cs и разместить там все аспекты уровня сборки. Вы правы, что AssemblyInfo.cs должно быть просто для метаданных на уровне сборки.

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

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

И откуда я знаю? С PostSharp у вас есть расширение Visual Studio. С AspectJ у вас есть плагин AspectJ для Eclipse (AJDT). Они показывают вам, внутри IDE, какие аспекты применяются к коду, который вы сейчас видите. И если вы действительно хотите увидеть детали (но вам редко очень хочется), вы можете использовать отладчик для перехода к аспектам или использовать Reflector для просмотра созданного кода.

Резюме:

1. Хороший дизайн АОП всегда начинается с хорошим дизайном ООП.
2. Избегайте полагаться на соглашения об именах для применения аспектов.
3. Используйте расширение PostSharp для Visual Studio или AJDT для визуализации аспектов вашего кода.

Answer 2

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

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

Я имею в виду отсутствие неуважения этим, хотя я уверен, что это будет интерпретироваться иначе.

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

Почему у меня возникла необходимость в использовании этого инструмента ? Какая проблема с дизайном I пытается решить?

После того, как у вас есть твердое понимание проблемы, пойти забрать Design Patterns Разъяснения (Shalloway & Тротта) или Head First Design Patterns (Freeman, Robson, Бейтс, & Sierra).

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