GRASP: принцип Indirection.

Проблема. Как распределить обязанности, чтобы обеспечить отсутствие прямого связывания? Как снизить уровень связывания объектов, согласно шаблону Low Coupling, и сохранить высокий потенциал повторного использования?

Решение. Присвоить обязанности промежуточному объекту для обеспечения связи между другими компонентами или службами, которые не связаны между собой напрямую.

При таком подходе связи перенаправляются к другим компонентами или службами.

Примеры

Класс Modem. Рассмотрим службу авторизации кредитной карты — класс CreditAuthorizationService. Допустим, что реализации этого класса необходимо использовать модем.

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

Лучшим решением является добавление посредника — класса Modem, который изолирует класса CreditAuthorizationService от API модема (рис. 9).

Рис. 9. Использование класса Modem для изоляции службы авторизации кредитных карт от низкоуровневого API модема

Класс PersistentStorage. В примере, приведенном при рассмотрении шаблона Pure Fabrication, класс Sale отделяется от служб взаимодействия с реляционной базой данных посредством введения класса PersistentStorage. Этот же пример соответствует реализации шаблона Indirection. Класс PersistentStorage выступает в роли промежуточного звена между классом Sale и БД.

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

Точно также, как многие шаблоны проектирования являются частным случаем шаблона Pure Fabrication, существует множество специализированных вариантов шаблона Indirection. Примерами таких шаблонов являются Adapter, Facade и Observer. Кроме того, многие вариации

шаблона Pure Fabrication зачастую базируются на основном принципе перенаправления связи по шаблону Indirection. Целью такого перенаправления обычно является слабое связывание, обеспечиваемое за счет отделения друг от друга различных компонентов или служб.

Замечание. Существует также и высказывание: «Большинство проблем, связанных с производительностью, можно решить, удалив новый уровень перенаправления».

Преимущество: слабое связывание между компонентами.

58.GRASP: принцип Polymorphism.

Проблема. Как обрабатывать альтернативные варианты поведения на основе типа?

Условная передача управления — это основная отличительная особенность любой программы. Если программа разработана с использованием условных операторов типа if-then-else (если-то-иначе) или операторов условного перехода по ключу, то при добавлении новых вариантов поведения приходится модифицировать логику условных операторов. Такой подход затрудняет процесс модификации программ в соответствии с новыми вариантами поведения, поскольку изменения приходится вносить сразу в нескольких местах программного кода — там, где используются условные операторы.

Решение. Если поведение объектов одного типа (класса) может изменяться, обязанности распределяются для различных вариантов поведения с использованием полиморфных операций для этого класса (а не с использованием проверки типа или условной логики).

Пример. POS-система NextGen должна поддерживать работу различных внешних систем вычисления налоговых платежей (в том числе Tax-Master и Good-As-Gold TaxPro) и интеграцию с другими внешними системами. Каждая система вычисления налоговых платежей имеет свой интерфейс и обладает собственным поведением (хотя и аналогичным поведению других систем). Один продукт может поддерживать протокол TCP, другой — интерфейс SOAP, а третий — интерфейс Java RMI.

Рис. 10. Использование полиморфизма при адаптации к различным внешним системам вычисления налоговых платежей

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

Поскольку поведение службы адаптации внешней системы вычисления налоговых платежей зависит от типа используемой программы вычисления, согласно шаблону Polymorphism, необходимо распределить обязанности по адаптации к различным типам этих программ. Для этого можно использовать полиморфную операцию getTaxes (рис. 10).

Каждому методу getTaxes в качестве параметра передается объект Sale, чтобы система вычисления налоговых платежей могла проанализировать продажу. Реализации каждого такого метода отличаются. Например, объект TaxMasterAdapter может адаптировать запросы к системе Tax-Master и т.п.

Назначение

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

· Новые реализации можно вводить без модификации клиентской части приложения.

Обсуждение. Полиморфизм — это основной принцип проектирования поведения системы в рамках обработки аналогичных ситуаций. Если обязанности в системе распределены на основе шаблона Polymorphism, то такую систему можно легко модифицировать, добавляя в нее новые

вариации.

Полиморфизм предполагает реализацию с использованием абстрактных классов или интерфейсов. Когда следует применять интерфейсы? Общая рекомендация состоит в том, что интерфейсы добавляются для поддержки полиморфизма при неизвестной заранее иерархии классов. Более того, интерфейсы обеспечивают «гибкую точку» вариаций для неизвестных ситуаций.

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

Когда не следует применять шаблон. Иногда разработчики систем злоупотребляют добавлением интерфейсов и применением принципа полиморфизма с целью обеспечения дееспособности системы в неизвестных заранее новых ситуациях. Если точка вариаций известна и обоснована, если существует высокая вероятность вариантного поведения, то такие усилия по обеспечению гибкости системы и применению принципа полиморфизма вполне оправданы. Однако к применению этого принципа нужно подходить критически, поскольку зачастую усилия по обеспечению вариантов поведения «на все случаи жизни» затрачиваются впустую.