АОП-паттерны программирования. Шаблон Adapter. Adapter языка Java.AspectJ Adapter.
Шаблон проектирования или паттерн (англ. design pattern) в разработке программного обеспечения — повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.
Что такое шаблон проектирования? Согласно " Шаблоны проектирования: Элементы повторно используемого объектно-ориентированного программного обеспечения " (обычно называемого GoF)
Шаблон проектирования систематично именует, мотивирует и объясняет общий дизайн, предназначенный для решения повторяющихся проблем в объектно-ориентированных системах. Он описывает проблему, решение, а также то, когда применять решение и каковы его последствия. Он также предоставляет советы по реализации и примеры. Решение представляет собой общую конфигурацию объектов и классов, решающих проблему. Решение настраивается и реализуется для решения проблемы в конкретном контексте.
Преимущества использования АОП в шаблонах проектирования
Первым ключевым преимуществом АОП является способность локализовать код данного шаблона проектирования. Это означает, что шаблон часто может быть реализован в одном аспекте или паре тесно связанных аспектов (в отличие от реализации языка Java, где приложение с шаблоном может распространиться по нескольким классам). Способность видеть весь код в единственном месте приводит к нескольким практическим выгодам. Во-первых, читатели кода могут более легко понять шаблон, если все его взаимодействия видимы в одном месте. Во вторых, если разработчики должны изменить реализацию шаблона, они могут сделать это изменение в одном месте, вместо того, чтобы искать фрагменты шаблона по всей системе. В-третьих, разработчики могут использовать понятные имена для описания аспекта, содержащего шаблон, обеспечивая таким образом текстовые подсказки относительно предназначения шаблона программистам, которые в дальнейшем будут поддерживать систему. Например, вы могли бы назвать аспект SensorAdapter, указывая, что применили шаблон Adapter к сенсорам.
|
|
Другое ключевое преимущество реализации шаблона AspectJ - забывчивость. Другими словами, классы, которые играют роль в шаблоне, не обязательно должны знать об этой роли. Эта выгода является прямым результатом локализации - поскольку шаблон локализован в аспекте, он не затрагивает его участников. Забывчивость делает код шаблона проще для понимания пользователями. Но не только это - забывчивость делает композицию шаблона намного проще. В Java-реализации, если класс участвует в нескольких шаблонах, его основное значение может быстро стать скрытым. Классы, которые не знают об их участии в шаблоне, могут также быть многократно использованы в других контекстах.
Шаблон Adapter
Первым шаблоном, который я рассмотрю детально, является Adapter. Adapter полностью посвящен совместимости. Шаблон позволяет классам взаимодействовать между собой, что в противном случае было бы невозможно из-за несовместимости интерфейсов. Для реализации Adapter в Java-коде вы заключаете класс (целевой класс) в специальный класс Adapter, который транслирует API целевого класса в тот, который ожидают пользователи, или в тот, который легче использовать.
|
|
Условие: Обеспечение агрегированного считывания данных датчиков
Допустим, вы проектируете космический корабль, и вас попросили обеспечить считывание всех критических датчиков. Поскольку вы расширяете существующую систему, для каждого датчика, к которому вы должны обратиться, уже существуют удобные классы Java.
К датчику радиации вы можете получить доступ следующим образом:
Некоторые из этих классов датчика были написаны другими членами группы, некоторые сторонними производителями. Вы хотели бы обеспечить отображение состояния каждого датчика так, чтобы руководитель экспедиции мог сразу увидеть, имеются ли на корабле проблемы. Вот пример того, что вы ищете. (Реальный экран, вероятно, повлек бы мигание красного света и клаксоны, но я пока буду придерживаться текстового варианта.)
Вы можете усовершенствовать экран, используя, например, следующий метод:
Чем дальше, тем лучше, но как опросить каждый датчик без обращения к ужасным проверкам оператором if(sensor instanceof XXX)? Одним из вариантов является изменение каждого класса датчика, а именно добавление метода getStatus(), интерпретирующего прочитанные данные датчика и возвращающего String, как показано ниже:
При этом посторонний для классов код отображения состояния вносится в несколько классов, повышая их сложность. Более того, могли бы существовать практические ограничения (такие как необходимость перекомпилирования классов сторонних производителей. Вот где нужен шаблон Adapter.
Adapter языка Java
Традиционная реализация шаблона Adapter окружает каждый целевой класс классом, реализующим удобный API. В этом случае вы создали бы общий интерфейс под названием, скажем, StatusSensor, показанный здесь:
|
|
Используя этот общий интерфейс вы могли бы реализовать чтение данных следующим образом:
Единственным остающимся вопросом является соответствие каждого датчика интерфейсу. Классы Adapter достигают этого. Как вы можете увидеть в листинге 1, каждый Adapter хранит датчик, который помещается в переменной-члене и использует этот датчик при реализации метода getStatus:
В листинге показан также "связующий код", который накладывает на каждый датчик соответствующий Adapter перед считыванием данных. Шаблон не требует, чтобы связующий код появлялся в каком-либо конкретном месте. Возможные месторасположения - "just after creation" и "just before use." В коде примера они помещаются прямо перед добавлением датчика к набору устройств индикации.