Практика управления сложностью методов метапрограммирования (АОП / отражения / макросов)

Question

Аспекты, макросы, отражения и другие тонкости - хорошие части

Я заметил, что уловки «метапрограммирования» (в мире замыканий у функций есть метаданные, в оо-мире у нас есть такие понятия, как рефлексия, АОП и т. Д.) Могут быть хорошим способом развязки и расширить функциональность существующего кода, не редактируя его. Такие приемы позволяют нам перехватывать, перенаправлять и переносить функциональные части нашего кода, чтобы он мог быть расширен динамичным способом.

Страшная часть

Однако, как утверждают многие, чрезмерное использование макросов может затруднить понимание кода. Шаблон архитектуры программного обеспечения «классной доски», где несколько агентов изменяют или редактируют общий ресурс, может быть опасным, если мы не будем тщательно управлять созданием этих агентов. Наконец, я хотел бы неофициально отметить, что давняя популярность C ++ и java, по крайней мере частично, обусловлена ​​тем фактом, что они являются языками «без сюрпризов» - где код является ясным, явным и процедурным. **

Проблема: перспектива использования методов динамического ввода кода для уменьшения количества компонентов и развязки котлов требует «нового» подхода к документации, проектированию классов и разработке программного обеспечения?

Мои вопросы

Требуется ли для того, чтобы документировать / развертывать обычный код, управлять исходными кодами, интегрировать библиотеки, другие или новые методы, когда мы начинаем приспосабливать методы метапрограммирования в сочетании с нашими более традиционными методологиями ОО?

Например, должны ли мы рассматривать использование метапрограммирования как альтернативу другим, более традиционным методам ОО программирования?

Существует ли общий набор известных красных флагов, введенных метапрограммированием, - и как мы можем их избежать?

Каковы наилучшие варианты использования аспектов, рефлексии и других динамических программных методов?

Answer 1

«Это зависит» :) ... Это, пожалуй, лучший ответ на все субъективные вопросы в мире программирования.

Я бы посоветовал перед тем, как использовать какую-либо технику, такую ​​как AOP или DI, дать ей очень серьезную информацию относительно того, действительно ли она вам действительно нужна. Мы как программисты очень увлекаемся этими новыми приемами и приемами, которые заставляют нас видеть красоту (поверхностную) в коде. Настоящая красота кода, к которому мы должны стремиться, - это простота и ничто иное.

Помните, что каждый новый трюк / техника / фреймворк, который вы добавляете в систему, будет увеличивать сложность системы (вероятно, в геометрической прогрессии).

Лично я придерживаюсь идеи: создавать программы, а не приложения, создавать библиотеки, а не фреймворки.

Answer 2

Вот цитата в ( SICP ), которая может иметь отношение к обсуждению:

"Без преувеличения можно считать это самой фундаментальной идеей в программировании:«Оценщик», который определяет значение выражений в языке программирования, является еще одной программой. Чтобы оценить этот момент, нужно изменить свои представления о себе как о программистах. Мы начинаем видеть себя в качестве разработчиков языков, а не только пользователей языков, разработанныхдругие. "

Answer 3

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