Шаблон Adapter существует достаточно комфортно в традиционной реализации. Что делает пересечение? Процесс "status" проходит через несколько различных классов датчиков. Если бы вы должны были разместить классы Adapter в пакете, ОО-реализация этого шаблона была бы достаточно модульной. Пакет стал бы "Модулем Adapter". Идиома наложения защищает датчики от знаний о шаблоне, что ведет к ослаблению связей. К сожалению, часть приложения, которое сделало наложение, должна будет знать и об Adapters и о датчиках, к которым они обращались. Таким образом, местоположение связующего кода тоже пересекалось бы шаблоном.
А теперь применим к Adapter на языке Java мои критерии оценки:
- Понимание: Так называемые SensorAdapters, расположенные в пакете, делают намерения этого шаблона понятными. К сожалению, связующий код может быть расположен далеко от пакета Adapter. Так как область связующего кода не структурирована, при попытке понять шаблон вы можете либо пропустить запутанный код, либо попытаться в нем разобраться.
Вы должны также побеспокоиться о работе по идентификации объекта. То есть, если в системе существуют версии одного и того же объекта, на которые было или не было применено наложение, вы должны выяснить, будут ли они эквивалентными. - Повторное использование: Для повторного использования этого шаблона вы должны реализовать его с нуля.
- Поддержка: При добавлении новых датчиков к системе вы должны добавить новые классы адаптеров и обновить связующий код, охватывающий их.
- Композиция: Допустим, что вы желаете привлечь датчики из другого шаблона. Датчики не знают об Adapter, поэтому будут не тронуты. Однако это палка о двух концах. Адаптированную или не адаптированную версию датчика должен рассматривать новый шаблон в качестве своего объекта?
|
|
AspectJ Adapter
Как и другие шаблоны проектирования AspectJ-реализация Adapter сохраняет назначение и концепции своих предшественников. Реализация использует объявления intertype - важный тип поддержки пересекающихся процессов, о котором говорят меньше, чем о pointcut и advice.
Как и в чистой ООП-версии, АОП-версия Adapter требует наличия интерфейса StatusSensor. Однако, вместо использования отдельных "накладывающихся" (wrapper) классов, AspectJ-версия использует форму declare parents для прямого внедрения StatusSensor в различные датчики, что показано ниже:
Теперь датчики должны соответствовать интерфейсу. Но они еще не реализуют интерфейс (о чем радостно сообщит вам компилятор AspectJ). Для завершения реализации шаблона вы должны добавить объявления методов intertype в аспект, для того чтобы реализовать соответствие датчиков. В приведенном ниже коде метод getStatus() добавлен к классу TemperatureGauge:
AspectJ-версия класса чтения данных выглядит так же, как версия, реализованная на Java, за исключением того, что для наложения на датчики не нужен связующий код. Каждый датчик "оборачивает" себя сам.
Анализ AspectJ Adapter
Ключевым преимуществом реализации Adapter в AspectJ является локализация. Шаблон полностью содержится внутри одного аспекта, а не в двух (или более) отдельных классах адаптеров и неструктурированной области оболочки. Применим к AspectJ–реализации мои критерии оценки:
- Понимание: Отсутствие "наложения" устраняет необходимость (для понимания шаблона) смотреть на что-либо еще, кроме аспекта Adapter. Устраняется также необходимость иметь дело с вопросами тождественности объектов.
- Повторное использование: AspectJ-версия является повторно используемой не больше и не меньше, чем другие версии.
- Поддержка: Поскольку для каждого нового датчика нужно лишь написание метода (а не целого класса), расширение реализации AspectJ должно быть немного более простым. По мере роста числа адаптеров или усложнении логики, требуемой для каждой адаптации, вы можете обнаружить, что один аспект становится чрезмерно большим. В этом случае вы можете разбить аспект на несколько более маленьких аспектов. При делении аспекта теряются некоторые из преимуществ локализации, но сохраняются другие преимущества.
- Композиция: Вы легко можете создать несколько шаблонов, поскольку нет проблемы координации "наложений".
|
|