Будет ли аспектно-ориентированное программирование положительным дополнением к языку C #? - PullRequest
Новая
       17

Будет ли аспектно-ориентированное программирование положительным дополнением к языку C #?

3 голосов
/ 21 октября 2009

У меня были интересные споры с коллегами о достоинствах, если включить аспектно-ориентированное программирование в качестве родной парадигмы для языка C #.

Дебаты, кажется, разделены на три лагеря:

  1. Те люди, которые думают, что C # уже слишком сложен, и еще одна важная функция, такая как AOP, только запутает воду.
  2. Те, кто думают, что это было бы отличным дополнением, потому что все, что может повысить выразительность языка, не нарушая существующего, - это хорошо.
  3. Те, кто не считает это необходимым, потому что библиотеки, такие как PostSharp, которые выполняют ткачество IL после компиляции, уже позволяют это независящим от языка способом.

Мне любопытно, что думает сообщество разработчиков C # / .NET.

Ответы [ 3 ]

2 голосов
/ 22 октября 2009

Было бы замечательно, если бы языки упростили для разработки и использования расширений AOP.

Например:

  • Было бы неплохо, если бы в качестве параметра пользовательского атрибута можно было передать делегата (или анонимный метод, или лямбду) в качестве параметра. Это не так много, чтобы реализовать это в C #, это довольно легко реализовать в CLR (так как он поддерживает типы, почему бы не методы?). И это позволило бы выразить «pointcuts» элегантно.

  • Поддержка 'fieldof' и 'methodof'. Это в некоторой степени поддерживается CLR (с ошибками), а не C #. То же самое для 'eventof' и 'propertyof' (в настоящее время они не поддерживают CLR).

  • Более совершенные символы отладки могут упростить ткачу сообщения о сообщениях об ошибках и указывать местоположение в коде.

  • Было бы здорово иметь модульный компилятор; было бы дешевле реализовать некоторые функции, такие как генерация исходного кода на основе аспектов (для введения методов и интерфейсов).

Тем не менее, я не думаю, что язык должен предоставлять расширения AOP. Это слишком много (я думаю, что PostSharp 2.0 более сложен, чем сам компилятор C #, по крайней мере, чем C # 2.0). Посмотрим правде в глаза: АОП все еще довольно экспериментален в том смысле, что мы до сих пор не знаем точно, что мы хотим от него. Еще мало опыта. Но мы хотим, чтобы спецификация языка была стабильной и решала хорошо понятые проблемы (представьте, что Entity Framework была частью языка).

Кроме того, существуют разные способы достижения АОП, и время сборки - только один из них. Нет ничего плохого в использовании технологий во время выполнения, таких как прокси с JIT (Spring / Castle); они предназначены только для разных вариантов использования и имеют свои плюсы и минусы.

Итак, мое мнение в одном предложении: да, для ограниченных и четко определенных языковых расширений, облегчающих разработку сред АОП; нет для полной реализации АОП на языке.

2 голосов
/ 21 октября 2009

Я согласен с первым лагерем. C # уже загружен функциями. Вместо этого используйте библиотеку PostSharp .

0 голосов
/ 21 октября 2009

Это было бы полезно, но многие из применений включены различными способами как есть. Например, у нас будет возможность выполнять пост-предварительную проверку в .NET4, которую можно было использовать в аспектеJ.

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

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

Я не знаю, захотят ли компании, которые склонны использовать .NET, использовать что-то вроде AOP, и вам потребуются инструменты, помогающие понять, какие аспекты вводятся, например AJDT в Eclipse.

...