59.Grasp: принцип Protected Variations.
Проблема. Как спроектировать объекты, подсистемы и систему, чтобы изменение этих элементов не оказывало нежелательного влияния на другие элементы?
Решение. Идентифицировать точки возможных вариаций или неустойчивости; распределить обязанности таким образом, чтобы обеспечить устойчивый интерфейс.
Термин «интерфейс» используется для обозначения способа обеспечения доступа и не сводится к понятиям интерфейса Java или COM.
Обсуждение. Protected Variations (PV) — это важный фундаментальный принцип разработки программных систем. Практически все основные свойства проектных решений (инкапсуляция, полиморфизм, проектирование на основе данных, интерфейсы, виртуальные машины и т. п.) являются частными случаями реализации этого шаблона.
Основные механизмы шаблона PV
Шаблон PV описывает ключевой принцип, на основе которого реализуются механизмы и шаблоны программирования и проектирования с целью обеспечения гибкости и защиты системы от влияния изменений внешних систем.
Базовые механизмы защиты от вариаций. Инкапсуляция данных, интерфейсы, полиморфизм, перенаправление — все эти принципы реализуются в рамках шаблона PV.
Проектирование на основе данных. Это широкий спектр методов, включая чтение кодов, значений, путей к файлам классов, имен классов из внешнего источника с целью обеспечения возможности изменения поведения или «параметризации» системы на этапе выполнения. К другим вариациям этих методов относятся листы стилей, метаданные для отображения объектов в реляционное представление, файлы свойств и т. д. Защита системы от изменения данных, метаданных или других изменений обеспечивается за счет внешнего расположения изменчивой информации и ее чтения на этапе выполнения программы.
Поиск служб. Поиск служб подразумевает использование служб именования (например, JDNI для Java или Naming Service для CORBA) или средств получения доступа к службе (например,Jini для Java или UDDI для веб-сервисов). Клиенты в этом случае защищены от изменения расположения служб: они могут использовать стандартный интерфейс поиска служб. Это — специальный случай проектирования на основе данных.
Проектирование на основе интерпретаторов. Проектирование на основе интерпретаторов предполагает включение интерпретаторов правил, выполняющих правила и считывающих их и внешнего источника, интерпретаторов сценариев или языков программирования, считывающих информацию и запускающих программы, виртуальных машин, нейронных сетей, механизмов реализации логики ограничений и т. д. Такой подход позволяет изменять или параметризировать поведение системы с помощью внешних логических выражений. Система защищена от изменения логики за счет внешнего расположения описания этой логики, считывания его и использования интерпретатора.
Рефлексивное проектирование (проектирование на метауровне). Примером реализации этого подхода является использование java.beans.Introspector для получения объекта BeanInfo, запрашивающего имя метода, реализующего свойство компонента Х и вызвающего метод invoke. При этом система остается защищенной от влияния логики изменения кода внешних компонентов за счет использования служб метаязыка. Это проектное решение является частным случаем проектирования на основе данных.
Унифицированный доступ. Некоторые языки, такие как Ada, Eiffel и C#, поддерживают синтаксические конструкции, при которых доступ к полям и методам классов осуществляется одинаково. Например, запись circle.Radius может означать и вызов метода get_Radius() (т. е. метод чтения значения свойства), и прямое обращение к открытому полю Radius, в зависимости от определения класса. Тогда открытые поля можно преобразовывать в свойства без изменения кода клиентских объектов.
Стандартные языки. Официальные стандарты языков (например, SQL) тоже обеспечивают выполнение шаблона PV.
Сокрытие структуры
Частным случаем шаблона PV является шаблон Don't Talk to Strangers (Не разговаривайте с незнакомцами) или Law of Demeter (закон Деметры).
Этот шаблон позволяет обеспечить устойчивость системы к изменению структуры объектов (это — довольно типичная точка неустойчивости).
Шаблон решает эту задачу путем ограничения перечня объектов, которым рассматриваемый объект может передавать сообщения. В рамках метода некоторого класса сообщения могут передаваться только следующим объектам:
объекту this (т. е. объекту разрешается вызывать свои методы);
параметру выполняемого метода;
атрибуту (полю) объекта this;
элементу коллекции, являющейся атрибутом объекта this;
объекту, созданному внутри метода.
Все эти объекты — это прямые объекты или «знакомые», а все остальные — непрямые или «незнакомцы». Закон Деметры предписывает объекту общаться только со «знакомыми» и не разговаривать с «незнакомцами», что позволяет избежать связывания с непрямыми объектами.
Пример. В общем виде ситуацию можно представить следующим образом:
В этом примере непрямому объекту передается сообщение путем установки цепочки связей. Причем, чем дальше по цепочке передается сообщение, тем неустойчивее становится связь между начальным и конечным объектами. А неустойчивость объектной структуры часто приводит к необходимости модификации кода, построенного на знании всех этих связей.
Для выполнения закона Деметры прямым объектам могу понадобиться новые операции, которые выступают в роли дополнительных операций, позволяющих избежать «разговоров с незнакомцами». Эти операции обеспечивают получение требуемой информации, оставляя «за кадром» способ ее получения. Например:
}
Код класса-клиента изменится следующим образом:
Закону Деметры не всегда нужно следовать. Все зависит от самой структура объектов. В стандартных библиотеках (например, в Java API или .NET Framework BCL) структурные связи между классами объектов довольно устойчивы. В почти готовых системах структура объектов тоже довольно устойчива. Однако, на ранних итерациях выполнения проекта объектная структура еще не стабильна.
Когда не следует применять шаблон PV. Следует определить два типа особых точек.
Точка вариации (variation point) — точка ветвления в существующей на данный момент системе или в требованиях к ней, например, необходимость поддержки нескольких интерфейсов для системы вычисления налоговых платежей.
Точка эволюции (evolution point) — предполагаемая точка ветвления, которая может возникнуть в будущем, однако не определяемая существующими требованиями.
Шаблон PV применяется и точкам вариации, и к точкам эволюции. Но иногда для реализации точек эволюции требуется гораздо больше усилий, чем для реализации простого проектного решения без учета этих точек. В таком случае лучше остановиться на неробастном решении и модифицировать его по мере необходимости (в случае реальных, а не предполагаемых изменений).
Часто программисты объектно-ориентированных систем пытаются создавать максимально обобщенный код и тратят много времени на создание суперклассов для действительно нужных им классов. Они стремятся добиться максимальной общности кода и его гибкости в расчете на последующие изменения, которые так никогда могут и не понадобиться.
Но если необходимость защиты от влияния возможных вариаций действительно существует, нужно придерживаться шаблона PV. Однако, если в системе зафиксированы лишь точки эволюции, вероятность реализации которых очень низка, то, принимая робастное проектное
решение, следует хорошо взвесить все «за» и «против».
Неопытные разработчики зачастую тяготеют к неробастным проектным решениям, более опытные уделяют слишком большое внимание гибкости системы и стремятся к обобщениям (даже если они никогда не понадобятся). Самые опытные специалисты выбирают промежуточное решение, тщательно оценивая вероятность возможных модификаций и усилия, необходимые для обеспечения робастного решения.
Преимущества
легкость добавления новых расширений и вариаций;
возможность добавления новых реализаций, не затрагивая клиента;
слабое связывание;
минимизация влияния изменений.