Проектирование с учётом будущих изменений.

Проектирование с учетом будущих изменений

при создании объекта явно указывается класс. Привязывает к конкретной реализации, а не к конкретному интерфейсу. Это может осложнить изменение объекта в будущем. Чтобы уйти от такой проблемы, создавайте объекты косвенно. Паттерны проектирования: абстрактная фабрика.

зависимость от конкретных операций. Задавая конкретную операцию, вы ограничиваете себя единственным способом выполнения запроса. Если же не включать запросы в код, то будет проще изменить способ удовлетворения запроса как на этапе компиляции, так и на этапе выполнения. Паттерны проектирования: цепочка обязанностей, команда;

зависимость от аппаратной и программной платформ. Паттерны проектирования: абстрактная фабрика, мост;

зависимость от представления или реализации объекта. Если клиент «знает», как устроен объект, то при изменении объекта может оказаться необходимым изменить и клиента. Сокрытие этой информации от клиентов поможет уберечься от каскада изменений. Паттерны проектирования: абстрактная фабрика, мост, хранитель, заместитель;

Зависимость от алгоритмов. Зависящие от алгоритмов объекты придется переписывать при каждом изменении алгоритма. Паттерны проектирования: итератор, стратегия, шаблонный метод, посетитель;

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

Расширение функциональности за счет порождения подклассов. Для определения подкласса необходимо ясно представлять себе устройство родительского класса. Кроме того, порождение подклассов ведет к комбинаторному росту числа классов.

Неудобства при изменении классов. Иногда нужно модифицировать класс, но делать это неудобно(нет исходного кода, влечёт изменения множества подклассов). Паттерны проектирования: адаптер, декоратор, посетитель.

Концепция программного компонента. Компоненты развертывания.

Понятие программного компонента (ПК) (software component)

В архитектуре ПО ПК (программный модуль) – произвольный и элемент структуры системы, решающий некоторые подзадачи и взаимодействующий с окружением через определенный интерфейс.

На диаграммах UML ПК (единицы сборки) — файлы с кодом, бинарные файлы, какие-либо документы, входящие в состав системы.

Компоненты развертывания – блоки, из которых строится компонентное программное обеспечение.

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

Компонентный каркас (component framework)

Состав:

Компонентная модель (component model) – набор правил определения интерфейсов компонентов и их реализаций, а также правил, по которым компоненты работают в системе (регламентирующие жизненный цикл компонента) и взаимодействуют друг с другом

Набор базовых служб (basic services) обеспечивающих например, обнаружение компонентов в среде (сетевой), передачу данных между компонентами (через сетевое взаимодействие)

Примеры:

различные реализации J2EE,

.NET,

CORBA.

Компонентные фреймворки. Компонентная модель.

Структура фреймворка

Основы принципов внедрения зависимостей. Инверсия управления.

Внедрение зависимости.

Внедрение зависимостей — это стиль настройки объекта, при котором поля объекта задаются внешней сущностью. DI — это альтернатива самонастройке объектов.

class ClassA { var classB: ClassB }

Класс ClassA содержит экземпляр класса ClassB, поэтому мы можем сказать, что класс ClassA зависит от класса ClassB. Классу ClassA нужен класс ClassB для корректной работы.

Согласно первому подходу з, а во втором подходе мы переместили обработку зависимостей из зависимого класса в пользовательский класс.

Варианты создания:

1. создавать зависимости в зависимом классе - зависимые классы отвечают за получение своих собственных зависимостей

 

class ClassA {

var classB: ClassB

fun someMethodOrConstructor() { classB = ClassB() classB.doSomething() }

}

Недостатки

§ когда нам нужно использовать ClassA, мы будем вынуждены использовать и ClassB, и заменить ClassB чем-то другим будет невозможно.

§ ClassA невозможно протестировать

§ СlassA должен знать, как создать ClassC и использовать его для создания ClassB.

1. внедрять зависимости через пользовательский класс - обработка зависимостей в пользовательском классе

 

class ClassA {

var classB: ClassB

constructor(classB: ClassB){ this.classB = classB }

}

Недостатки

• пользовательский код нетривиален и сложен в управлении.

1. Ответственность за обработку зависимостей возлагается на третью сторону

 

• фреймворки для внедрения зависимостей упрощают работу и позволяет избежать написания шаблонного кода
• фреймворки предлагают способ определения полей (объектов), которые должны быть внедрены.
• фреймворки позволяют определить, как нужно предоставить каждую зависимость