Почему использование компилятор сообщения?

Давайте попробуем остановиться на архитектурной стороне вопроса. Допустим, вы архитектор (каждый хочет быть архитектором;) Вам необходимо передать архитектуру своей команде: выбранный набор библиотек, архитектурных шаблонов и шаблонов проектирования. В рамках вашего проекта вы говорите: «Мы реализуем кэширование, используя следующий шаблон проектирования:»

string key = string.Format("[{0}].MyMethod({1},{2})", this, param1, param2 );
T value;
if ( !cache.TryGetValue( key, out value ) )
{
   using ( cache.Lock(key) )
   {
      if (!cache.TryGetValue( key, out value ) )
      {
         // Do the real job here and store the value into variable 'value'.
         cache.Add( key, value );
      }
   }
}

Это правильный способ выполнения трассировки. Разработчики собираются реализовать этот шаблон тысячи раз, поэтому вы напишете хороший документ Word, рассказывающий, как вы хотите реализовать этот шаблон. Да, документ Word. У вас есть лучшее решение? Боюсь, что нет. Классические генераторы кода не помогут. Функциональное программирование (делегаты)? Он работает довольно хорошо для некоторых аспектов, но не здесь: вам нужно передать параметры метода в шаблон. Так что осталось? Опишите шаблон на естественном языке и доверьтесь, что разработчики реализуют их.

Что произойдет?

Сначала какой-нибудь младший разработчик посмотрит на код и скажет: «Хм. Два просмотра кеша. Вроде бесполезно. Одного достаточно. "(Это не шутка - спросите об этом команду DNN). И ваши шаблоны перестают быть потокобезопасными.

Как архитектор, как вы гарантируете, что шаблон правильно применяется? Тестирование? Достаточно честно, но таким образом вы вряд ли обнаружите проблемы с потоками. Обзор кода? Возможно, это решение.

Итак, что вы решили изменить шаблон? Например, вы обнаружили ошибку в компоненте кеширования и решили использовать свой собственный? Собираетесь ли вы редактировать тысячи методов? Это не просто рефакторинг: что, если новый компонент имеет другую семантику?

Что делать, если вы решите, что метод больше не будет кэшироваться? Насколько сложно будет удалить кэширующий код?

Решение АОП (какой бы ни была его структура) имеет следующие преимущества перед простым кодом:

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

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

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

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

Аспекты убирают весь код копирования и вставки и ускоряют добавление новых функций.

Я ненавижу ничего больше, чем, например, необходимость писать один и тот же фрагмент кода снова и снова. У Гаэля есть очень хороший пример INotifyPropertyChanged на его веб-сайте (www.postsharp.net).

Это именно то, для чего предназначен АОП.Забудьте о технических деталях, просто реализуйте то, что вас просят.

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

Будущее принадлежит декларативному функциональному стилю, который удерживается объектно-ориентированной структурой, а сквозные проблемы решаются с помощью аспектов.

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