Внутренние связи вариантов

При описании механизмов, предназначенных для внутренней связи, будем считать, что ПС создается в парадигме ООП, где каждый компонент ПС представлен классом с собственными данными и методами их обработки, а следовательно, все варианты, с которыми пользователь имеет дело, при реализации представляют собой не что иное, как простые манипуляции классами или другими конструкциями используемого ЯП.

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

1. Композиция. Механизм вариабельности устанавливается на основе связи между объектами типа «part» и размещения общей части в делегирующем классе, а переменной — в делегированном. На рис. 4.2 представлены UML-схема и соответствующий фрагмент кода, который описывает поведенис системы в случае изменения расположения панели с элементами управления в окне.

Рис. 4.2. Композиция.

Окно не содержит логики относительно того, как именно отображать и группировать разные элементы управления. Окно делегирует эту функцию панели. Команда панель. Горизонтально = true является общей частью, которая выполняется одинаково в независимости от типа панели и элемента управления (ЭУ). Переменная часть находится в панели переписанного ЭУ и содержит соответствующую логику расположения и отображения элемента для разных ЭУ.

class Окно {.

List панели = new ЫБ1: (); public Окно () {.

foreach (Панель панель in панели) { панель. Горизонтально = true; }.

}.

}.

class Панель {.

Ыз^ЭлементУправления> ЭлементыУправления = new List.

() ;

public bool Горизонтально {.

get { return горизонтально; }.

set {.

горизонтально = value;

Перерисовать ЭУ ();}.

}.

private bool Горизонтально;

private void Переписать ЭУ (){/*…*/} }.

class ЭлементУправления {/*…*/.

В данном примере общей частью является интерфейс работы с классом Панель и свойством Горизонтально. Перерисовываются ЭУ, которые содержат механизм вариации. Эти компоненты реализованы во всех других порожденных типах Панелей и ЭУ соответственно, а, следовательно, переменной частью является содержание каждого из этих методов и свойств. Вариантами являются объекты, которые сохраняются в коллекциях: 1л. ч1 ЭлементыУправления и 1л51 панели.

На данном примере связь между классами Панель и ЭУ является примером агрегации объектов — панель может содержать несколько ЭУ; связь между классами Окно и Панель — примеры композиции объектов, где к отношению «part-of» добавляется условие, что панель принадлежит только одному окну и уничтожается вместе с ним. Обобщением обоих отношений (агрегации и композиции) выступает ассоциация.

2. Наследование. Механизм базируется на таком принципе ООП, как наследование через установление отношений «наследник — предок» с возможностью порождать один класс объектов от другого с сохранением всех свойств и методов класса-предка, а следовательно, и руководить объектами, не имея полной информации о них.

Этот механизм разделяет общую функциональность в базовом классе и дополненную в классе наследника. Наследование имеет следующие виды категорий.

Множественное наследование (рис. 4.3). При таком механизме реализации вариабельности новый класс наследуется от нескольких базовых.

Рис. 4.3. Множественное наследование.

Стандартное наследование (рис. 4.4). Предусматривает создание иерархической структуры кода, который содержит более общую функциональность на верхнем уровне (в базовом классе — ЭУ) для последующего использования ее на нижнем уровне, дополненном варьирующейся функциональностью (классы-наследники). Таким образом, классы становятся более специализированными.

Наследование с виртуальными методами. Механизм подобен стандартному наследованию, но методы базового класса могут быть загружены классом-наследником.

На данном рисунке класс управления содержит алгоритмы сортировки и поиска и не зависит от элементов, над которыми выполняется операция. Такой тип наследования поддерживается в ЯП: Eiffel, С, Dylan, Python, Perl, Curl, Common Lisp (через CLOS), OCaml.

Наследование, основанное на смесях. Смесь (mix) — элемент ЯП (абстрактный подкласс или модуль), который реализует вариант поведения родительского класса или модуля. При реализации вариабельности он используется для уточнения поведения других классов и не предназначен для порождения самостоятельно используемых объектов ЯП, которые поддерживают смеси, — это: Flavors, Smalltalk, Beta, CLOS, Ruby, D, Python, Scala. На рис. 4.5 изображена UML-схема реализации наследования со смесью.

На данном рисунке интерфейс потребности описывает через методы Смесь и получает информацию от предка. Любой класс, в котором будет использоваться Смесь, должен реализовывать методы интерфейса Услуги. Классы Алгоритмы 1 и Алгоритмы2 в данном случае являются примесями. В классе упорядочен Список смешивания обоих классов. Ниже представлен фрагмент программы для реализации механизма вариации типа Смесь:

Рис. 4.4. Пример стандартного наследования классов.

Рис. 4.5. Имитация множественного наследования interface Услуги.

{.

void Упорядочить (); object Найти (/*элемент*/);

}.

interface Потребность { object Получение Элемент (int номер);} class Алгоритмы1: Услуги {.

private readonly Потребности список;

public Алгоритмы1(Потребности список) { this. список = список; } public void Упорядочить ().

{.

/*Алгоритм упорядоченности списка, который находится в parent*/.

}.

public object Найти (/*элемент*/) {/*Алгоритм поиска в список. ПолучитьЭлементы ();*/}.

}.

class Алгоритмы2: Услуги.

{.

private readonly Потребности список;

public Алгоритмы2(Потребность список) {this.список = список; }.

public void Упорядочить () { }.

public object Найти (/*элемент*/) {/*…*/}.

}.

class СписокЭлементов.

{.

private object[] элементы;

public СписокЭлементов () {элементы = new object[10]; } public object Получить Элемент (int номер) {return элементы[номер]; }.

public void ДобавитьЭлемент (object элемент) {/*ДобавитьЭлемент.

*/ }.

}.

class Упорядоченный Список: СписокЭлементов, Потребности, Услуги {.

private readonly Услуги mixin; public Упорядочить Список () base () {.

if (/*ограничена память*/) {this.mixin = new Алгоритмы1(this) ;

} else if (/*свободный процессор*/).

{this.mixin = new Алгоритмы2(this);}.

}.

public void Упорядочить () {mixin.Упорядочить (); } public object найти (/*элемент*/) {object элемент = mixin. Найти (/*элемент*/); }.

}.

В этом фрагменте точка вариации представлена в коде командой this, mixin = new A.'iropriTMbi2(this).

Если возникнет необходимость изменить алгоритм сортировки или поиска, который реализован в классе Алгоритмы!, достаточно изменить Алгоритмы1 на другой класс, унаследованный от интерфейса Услуги. Переменная часть представлена классами Алгоритмы1 и Алгоритмы2, Общие — интерфейсы Потребности и Услуги и классы Список Элементов и Упорядоченный Список. Выбранный Вариант сохраняется в переменной private readonly Услуги mixin, а Механизм Вариации — это оператор if в конструкторе public Упорядоченный Список.

Наследование, основанное на объектах или шаблоне делегирования {delegation pattern). Это механизм вариации, который, в отличие от других, применяется на уровне объектов, а не классов. Это способ, которым объект внешне демонстрирует некоторое поведение, но фактически передает ответственность за выполнение соответствующего действия другому объекту, как в следующем примере, где Принтер делегирует объект типа Принтер.

class Принтер {//делегированный void печатать () {/*.*/}}.

class Принтер {// делегирующий Принтер принтер = new Принтер (); void print () {принтер.печатать (); }.

}.

• 3. Параметризация. Параметризованным типом может быть класс, структура, интерфейс или метод, в котором есть ссылка на место конкретизации параметров одного или нескольких типов, которыми он оперирует или которые сохраняются (конструкция вроде placeholders (type parameters)). Этот механизм вариации предусматривает наличие общего кода для работы с разными типами данных. Яркими представителями являются шаблоны и универсальные шаблоны. Они являются синтаксически и функционально подобными, но различаются внутренним механизмом реализации. Пример использования включает переменные: List и 1лз1<�ЭлементУправлениях Они могут сохранять массивы объектов любых типов, порожденных от типов Панели и ЭУ соответственно. При этом алгоритм работы остается непеременным.
• 4. Перегрузка. Сущность этого механизма заключается в вариации типов, над которыми выполняется оператор или за которыми вызывается функция. То есть ЯП предоставляет возможность повторного использования имени для операции над другими типами. Выбор варианта осуществляет программная среда ЯП. Применяется к процедурам, функциям или операторам. Языки, которые поддерживают перегрузку: Ada, C++, С#, D, Erlang, F#, Groovy, Java, JavaScript, Haskell, Common Lisp, Nemerle, Scala, VB.NET, Delphi, Ocaml. Язык Java не поддерживает перегрузку операторов, но выполняет внутреннюю перегрузку оператора «+» для сочетания строк. В С#, например, можно перегружать методы, унарные и бинарные операторы.

Использование этого механизма можно рассмотреть на примере метода public object Найти (/*элемент*/). Система сама решит, что возвращать как результат: найденный элемент или его позицию в списке, если разработчик добавит еще один метод с таким же названием, но другим исходным параметром, public int Найти (/*элсмент*/).

• 5. Динамическая загрузка классов. Сущность механизма заключается в том, что класс загружается в память лишь тогда, когда он действительно начинает использоваться так, как реализовано, например, в виртуальной машине языка Java. Для управления этой функциональностью используется (MainClass.class.getClass Loader ();).
• 6. Отображение. Механизм, основанный на способности программы модифицироваться, имеет собственное поведение. Такие манипуляции достигаются благодаря делению ПС на базовое и цель уровня. Цель уровня предоставляет информацию об избранных системных свойствах, поскольку базовый уровень, который включает логику программы, ориентирован на цель уровня, на изменение цели уровня и влияет на поведение базового уровня. В СПС общая функциональность расположена на базовом уровне и может меняться во время работы в зависимости от конфигурационной информации, которая используется на уровнях.

Пример реализации отображения в языке С#:

//Без отображения Университет унив = new Университет ();

унив.СписокФакультетов () ;

//Отображение.

Type type = Type. GetType (.

«UnivercityNamespace. Университет «);

object univ = Activator. Createlnstance (t);

type.InvokeMember («СписокФакультетов «, ВindingFIags .

InvokeMethod, null, univ, null);

7. Шаблоны (или паттерны) архитектуры и проектирования {patterns) могут использоваться в СПС, потому что большинство из них предоставляет готовые решения для управления вариабельностью (рис. 4.6).

Применение шаблонов покрывает некоторые предыдущие механизмы, такие как: агрегация, подобие и параметризация.

Класс Абстракция определяет абстрактный интерфейс для Клиента и содержит переменную исполнитель типа Исполнитель. Конкретизация Абстракции расширяет интерфейс, определенный Абстракцией.

Рис. 4.6. Шаблон.

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

Рассмотренные механизмы вариации не покрывают всю проблемную область обеспечения вариантов, но являются наиболее используемыми в парадигме ООП. Они могут быть применены в других парадигмах, а некоторые из них концептуально заложены в эти парадигмы и могут служить инструментами вариации ПС.