Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО

Нажмите для полного просмотра!

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №2

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №3

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №4

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №5

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №6

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №7

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №8

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №9

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №10

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №11

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №12

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №13

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №14

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №15

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №16

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №17

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №18

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №19

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №20

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №21

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №22

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №23

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №24

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №25

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №26

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №27

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №28

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №29

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №30

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №31

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №32

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №33

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №34

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №35

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №36

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №37

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №38

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №39

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №40

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №41

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №42

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №43

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №44

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №45

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №46

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №47

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №48

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №49

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №50

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №51

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №52

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №53

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №54

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №55

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №56

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №57

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №58

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №59

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №60

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №61

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №62

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №63

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №64

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №65

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №66

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №67

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №68

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №69

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №70

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №71

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №72

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №73

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №74

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №75

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №76

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №77

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №78

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №79

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №80

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №81

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №82

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №83

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №84

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №85

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №86

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №87

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №88

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №89

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №90

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №91

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №92

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №93

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №94

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №95

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №96

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №97

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №98

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №99

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №100

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №101

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №102

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №103

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №104

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №105

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №106

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №107

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №108

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №109

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №110

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №111

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №112

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №113

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №114

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №115

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №116

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №117

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №118

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №119

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №120

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №121

Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО, слайд №122

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Технология разработки программного обеспечения (вторая часть). Порождающие шаблоны проектирования ПО. Доклад-сообщение содержит 122 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Технология разработки программного обеспечения (вторая часть) Порождающие шаблоны проектирования ПО проф. каф. ОСУ Тузовский А.Ф. Лекция 6

Слайд 2

Описание слайда:

1. Порождающие паттерны Порождающие паттерны проектирования абстрагируют процесс создания объектов класса. Они помогают сделать систему независимой от способа создания, композиции, и представления объектов. Позволяют ответить на вопрос: кто, когда и как создает объекты в системе. Abstract Factory (Абстрактная фабрика) Buildеr (Строитель) Factory Method (Фабричный метод) Prototype (Прототип) Singleton (Одиночка)

Слайд 3

Описание слайда:

1.1. Паттерн Abstract Factory (Абстрактная фабрика) Название паттерна Abstract Factory / Абстрактная фабрика другие названия: Toolkit / Инструментарий Factory/Фабрика Цель паттерна предоставить интерфейс для проектирования и реализации семейства, взаимосвязанных и взаимозависимых объектов, не указывая конкретных классов, объекты которых будут создаваться.

Слайд 4

Описание слайда:

Пояснение В соответствии с принцип инверсии зависимости (DIP) следует использовать зависимости от абстрактных классов и избегать зависимостей от конкретных классов, особенно когда последние изменчивы. Нарушение принципа DIP: Circle c = new Circle(origin, 1); Здесь Circle – конкретный класс, значит, модули, которые создают экземпляры Circle, обязательно нарушают DIP. Любой код, в котором используется ключевое слово new, не согласуется с принципом DIP.

Слайд 5

Описание слайда:

Часто нарушение принципа DIP практически безвредно. Чем выше вероятность того, что конкретный класс будет изменяться, тем вероятнее, что зависимость от него приведет к неприятностям. если конкретный класс не склонен к изменениям, то ничего страшного в зависимости от него нет. Например: создание объектов типа string не вызывает у меня беспокойства. Зависимость от класса string вполне безопасна, потому что в обозримом будущем этот класс не изменится.

Слайд 6

Описание слайда:

При активной разработки приложения многие конкретные классы часто изменяются – зависимость от них может стать источником проблем. Лучше зависеть от абстрактного интерфейса, тогда программа будем изолированы от большинства изменений. Паттерн Abstract Factory позволяет создавать конкретные объекты, не выходя за рамки зависимости от абстрактного интерфейса. Он очень полезен на тех этапах разработки приложения когда конкретные классы еще очень изменчивы.

Слайд 7

Описание слайда:

Когда следует испрользовать паттерн Abstract Factory система не должна зависеть от того, как в ней создаются и компонуются объекты; объекты, входящие в семейство, должны использоваться вместе; система должна конфигурироваться одним из семейств объектов; надо предоставить интерфейс библиотеки, не раскрывая её внутреннюю реализацию.

Слайд 8

Описание слайда:

Пример – игра «Супер Ралли» (гонка на автомобилях) Одно из требований: игрок должен иметь возможность выбирать себе автомобиль для участия в гонках. Каждый из автомобилей состоит из специфического набора составляющих: двигатель, колес, кузов, коробка передач, бензобак определяют возможности автомобиля (скорость, маневренность, устойчивость к повреждениям, длительность непрерывной гонки без перезаправки и д.р.). Может быть много разных типов автомобилей. Их количество может изменяться динамически (например, в зависимости от опыта игрока). Клиентский код, выполняющий конфигурирование автомобиля специфичным семейством составляющих, не должен зависеть от типа выбранного автомобиля.

Слайд 9

Описание слайда:

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

Слайд 10

Описание слайда:

Диаграмма классов

Слайд 11

Описание слайда:

Клиентский код, который «собирает» автомобиль из деталей, использует интерфейсную ссылку ФабрикаСоставляющих, методы данного интерфейса возвращают ссылки на абстрактные составляющие. Можно передавать клиенту объект конкретной фабрики, которая создает семейство объектов конкретных составляющих.

Слайд 12

Описание слайда:

Общая структура паттерна Abstract Factory

Слайд 13

Описание слайда:

Участники паттерна Abstract Factory Интерфейс AbstractFactory — абстрактная фабрика Предоставляет общий интерфейс для создания семейства продуктов. Класс ConcreteFactory — конкретная фабрика Реализует интерфейс AbstractFactory и создает семейство конкретных продуктов. Метод интерфейса AbstractProdact — абстрактный продукт Предоставляет интерфейс абстрактного продукта, ссылку на который возвращают методы фабрик. Метод класса ConcreteProdact — конкретный продукт Реализует конкретный тип продукта, который создается конкретной фабрикой.

Слайд 14

Описание слайда:

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

Слайд 15

Описание слайда:

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

Слайд 16

Описание слайда:

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

Слайд 17

Описание слайда:

Практический пример использования паттерна Задача – разработать ПО для магазина компьютерной техники. Одно из требований – быстрое создание конфигурации системного блока. Предположим, что в состав конфигурации системного блока входят: бокс (Box); процессор (Processor); системная плата (MainBoard); жесткий диск (Hdd); оперативная память (Memory).

Слайд 18

Описание слайда:

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

Слайд 19

Описание слайда:

Класс персонального компьютера Рс Класс, представляющий конфигурацию системного блока: public class Pc { public Box Box { get; set; } public Processor Processor { get; set; } public MainBoard MainBoard { get; set; } public Hdd Hdd { get; set; } public Memory Memory { get; set; } }

Слайд 20

Описание слайда:

Интерфейс фабрики создания конфигурации системного блока Ответственность за их создание заданной конфигурации надо возложить на один класс-фабрику. Эта фабрика должна реализовать интерфейс IPcFactory . Методы это интерфейса возвращают ссылки на классы абстрактных продуктов. public interface IPcFactory { Box CreateBox ( ) ; Processor CreateProcessor ( ) ; MainBoard CreateMainBoard ( ) ; Hdd CreateHddO ; Memory CreateMemory ( ) ; }

Слайд 21

Описание слайда:

Для создания компонентов конфигураций определяем классы конкретных фабрик HomePcFactory OfficePcFactory. В каждом из create-методов этих классов создается объект конкретного класса продукта, соответствующего типу конфигурации.

Слайд 22

Описание слайда:

Класс HomePcFactory Фабрика для создания "домашней" конфигурации системного блока ПК public class HomePcFactory : IPcFactory { public Box CreateBox() { return new SilverBox(); } public Processor CreateProcessor() {return new IntelProcessor(); } public MainBoard CreateMainBoard() { return new MSIMainBord(); } public Hdd CreateHddO { return new SamsungHDD(); } public Memory CreateMemory() { return new Ddr2Memory();} }

Слайд 23

Описание слайда:

Класс OfficePcFactory Фабрика для создания "офисной" конфигурации системного блока ПК public class OfficePcFactory : IPcFactory { public Box CreateBox() {return new BlackBoxf); } public Processor CreateProcessor() { return new AmdProcessor();} public MainBoard CreateMainBoard() {return new AsusMainBord(); } public Hdd CreateHdd{) {return new LGHDD ();} public Memory CreateMemory() { return new DdrMemory(); } }

Слайд 24

Описание слайда:

Класс PcConfigurator Ответственен за создание объекта типа Рс выбранного типа public class PcConfigurator { public IPcFactory PcFactory { get; set; } public void Configure(Pc pc) { pc.Box = PcFactory.CreateBox(); pc. MainBoard = PcFactory.CreateMainBoard(); pc.Hdd = PcFactory.CreateHdd() ; pc.Memory = PcFactory.CreateMemory(); pc.Processor = PcFactory.CreateProcessor(); } }

Слайд 25

Описание слайда:

Полная диаграмма классов

Слайд 26

Описание слайда:

Класс PcConfigurator принимает экземпляр конкретной фабрики и с помощью её методов создает составляющие персонального компьютера. PcConfigurator работает с интерфейсной ссылкой IPcFactory и ничего не знает о конкретных фабриках конфигураций и конкретных составляющих. Cила абстрактной фабрики конкретную фабрику можно определять на этапе выполнения программы клиентский код не зависит от конкретных фабрик или конкретных продуктов.

Слайд 27

Описание слайда:

Паттерн Factory (Фабрика) В соответствии с принцип инверсии зависимости следует использовать зависимости от абстрактных классов и избегать зависимостей от конкретных классов, особенно когда последние изменчивы. Следующий фрагмент кода нарушает принцип DIP: Circle c = new Circle(origin, 1); Здесь Circle – конкретный класс, значит, модули, которые создают экземпляры Circle, обязательно нарушают DIP. Любой код, в котором используется ключевое слово new, не согласуется с принципом DIP.

Слайд 28

Описание слайда:

Достаточно часто нарушение принципа DIP практически безвредно. Чем выше вероятность того, что конкретный класс будет изменяться, тем вероятнее, что зависимость от него приведет к неприятностям. Но если конкретный класс не склонен к изменениям, то ничего страшного в зависимости от него нет. Так, создание объектов типа string не вызывает у меня беспокойства. Зависимость от класса string вполне безопасна, потому что в обозримом будущем этот класс не изменится.

Слайд 29

Описание слайда:

Однако, во время активной разработки приложения многие конкретные классы часто изменяются, поэтому зависимость от них может стать источником проблем. Лучше зависеть от абстрактного интерфейса, тогда программа будем изолированы от большинства изменений. Паттерн Factory (Фабрика) позволяет создавать конкретные объекты, не выходя за рамки зависимости от абстрактного интерфейса. Он очень полезен на тех этапах разработки приложения когда конкретные классы еще очень изменчивы.

Слайд 30

Описание слайда:

Пример программы Имеется класс SomeApp, зависящий от интерфейса Shape. SomeApp обращается к экземплярам Shape исключительно через интерфейс Shape и не пользуется методами, специфичными для классов Square или Circle. К сожалению, SomeApp также создает экземпляры Square и Circle и, следовательно, зависит от этих конкретных классов.

Слайд 31

Описание слайда:

Применение паттерна Фабрика к классу SomeApp Интерфейс ShapeFactory, в котором объявлены два метода: MakeSquare() возвращает экземпляр Square, MakeCircle() возвращает экземпляр Circle. В обоих случаях возвращаемое значение имеет тип Shape.

Слайд 32

Описание слайда:

public interface ShapeFactory { Shape MakeCircle(); Shape MakeSquare(); } public class ShapeFactoryImplementation : ShapeFactory { public Shape MakeCircle() { return new Circle(); } public Shape MakeSquare() { return new Square(); } }

Слайд 33

Описание слайда:

Этот прием полностью решает проблему зависимости от конкретных классов. Код приложения не зависит от Circle и Square, но может успешно создавать объекты обоих классов. Он манипулирует этими объектами через интерфейс Shape и никогда не вызывает методов, специфичных только для Square или Circle. Проблема зависимости от конкретного класса перенесена в другое место.

Слайд 34

Описание слайда:

Экземпляр ShapeFactoryImplementation где-то должен создаваться. Но больше ни в одном месте объекты Square и Circle напрямую не создаются. Экземпляр ShapeFactoryImplementation, обычно создается в головной программе или в специальном методе инициализации, который вызывается из Main.

Слайд 35

Описание слайда:

Проблема зависимости В описанном варианте паттерна Фабрика имеется проблема. В интерфейсе ShapeFactory объявлены методы для всех классов, производных от Shape. Это приводит к зависимости по именам, усложняющей добавление новых подклассов Shape. При добавлении каждого нового подкласса нужно также добавить новый метод в интерфейс ShapeFactory. придется заново откомпилировать и развернуть все клиенты ShapeFactory.

Слайд 36

Описание слайда:

Можно избавиться от этой проблемы, частично пожертвовав безопасностью типов. Вместо того чтобы вводить в ShapeFactory по одному методу для каждого подкласса Shape, можно оставить всего один метод, принимающий строку. [Test] public void TestCreateCircle() { Shape s = factory.Make(“Circle”); Assert.IsTrue(s is Circle); }

Слайд 37

Описание слайда:

В этом случае в классе ShapeFactoryImplementation нужно будет использовать цепочку предложений if/else, в которых входной аргумент анализируется на предмет выбора подходящего подкласса Shape. public interface ShapeFactory { Shape Make(string name); } public class ShapeFactoryImplementation : ShapeFactory { public Shape Make(string name) { if(name.Equals(“Circle”)) return new Circle(); else if(name.Equals(“Square”)) return new Square(); else throw new Exception(“ShapeFactory не может создать: {0}”, name); } }

Слайд 38

Описание слайда:

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

Слайд 39

Описание слайда:

Слайд 40

Описание слайда:

Взаимозаменяемые фабрики Большое достоинство фабрик – возможность подменять одну реализацию фабрики другой. Это позволяет подставлять в приложение различные семейства объектов. Например, пишется приложение, которое должно адаптироваться к нескольким реализациям базы данных. Допустим, что можно либо работать с плоскими файлами, либо купить адаптер к СУБД Oracle. Чтобы изолировать приложение от реализации базы данных, можно воспользоваться паттерном Proxy (Заместитель). А для создания экземпляров заместителей можно применить фабрики.

Слайд 41

Описание слайда:

Диаграмма классов Есть две реализации интерфейса EmployeeFactory. одна создает объекты-заместители для работы с плоскими файлами, другая – для работы с Oracle. Приложение не знает о том, какая реализация используется.

Слайд 42

Описание слайда:

Слайд 43

Описание слайда:

Слайд 44

Описание слайда:

Слайд 45

Описание слайда:

Слайд 46

Описание слайда:

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

Слайд 47

Описание слайда:

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

Слайд 48

Описание слайда:

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

Слайд 49

Описание слайда:

Выводы Шаблон Фабрика – это мощный инструмент. Она может оказаться ценным инструментом, обеспечивающим согласование с принципом DIP, (позволяет модулям верхнего уровня создавать экземпляры классов, не становясь зависимыми от конкретных реализаций этих классов). дают возможность подменять целые семейства реализаций групп классов. Но Фабрики вносят сложность, без которой часто можно обойтись. Повсеместное их применение редко бывает оптимальным курсом.

Слайд 50

Описание слайда:

1.2. Паттерн Buildеr (Строитель) Название паттерна Buildеr / Строитель. Цель паттерна отделяет процесс построения сложного объекта от его представления – в результате одного и того же процесса создания получаются разные представления объекта. клиентский код может порождать сложный объект, определит для него не только тип, но и внутреннее содержимое. клиент не обязан знать о деталях конструирования объекта.

Слайд 51

Описание слайда:

Паттерн Buildеr следует использовать когда... Общий алгоритм построения сложного объекта не должен зависеть от специфики каждого из его шагов. В результате одного и того же алгоритма конструирования надо получить различные продукты.

Слайд 52

Описание слайда:

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

Слайд 53

Описание слайда:

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

Слайд 54

Описание слайда:

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

Слайд 55

Описание слайда:

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

Слайд 56

Описание слайда:

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

Слайд 57

Описание слайда:

В результате применения конкретных подклассов класса ТехнологияМодели можно получать на выходе разные модели автомобилей, т.е. экземпляры разных классов автомобилей. В данном случае определим такие подклассы класса ТехнологияМодели: ТехнологияМиниАвто, ТехнологияСпортивныйАвто, ТехнологияВнедорожныйАвто.

Слайд 58

Описание слайда:

Каждая из этих технологий соответственно предусматривает выпуск таких моделей автомобилей: МиниАвто, СпортивныйАвто, ВседорожныйАвто.

Слайд 59

Описание слайда:

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

Слайд 60

Описание слайда:

Диаграмма классов модели конвейера по производству автомобилем

Слайд 61

Описание слайда:

Преимущества паттерна 1) конкретная технология построения создается по общему шаблону, реализуя действия, которые он определяет; 2) общий алгоритм процесса построения не зависит от деталей, специфических для конкретной технологии; есть возможность без опасности увеличения сложности структуры модели реализовать под общий алгоритм большое количество конкретных технологий.

Слайд 62

Описание слайда:

Структура паттерна Builder

Слайд 63

Описание слайда:

Участники паттерна Director (Конвейер) – распорядитель Определяет общий алгоритм конструирования, используя для реализации отдельных шагов возможности класса Builder. Builder (ТехнологияМодели) — строитель Обеспечивает интерфейс для пошагового конструирования сложного объекта (продукта) из частей. ConcreteBuilder (ТехнологпяМиниАвто и др.) — конкретный строитель Реализует шаги построения сложного объекта, определенные в базовом классе Builder. Создает результат построения (Product) и следит за пошаговым конструированием. Определят интерфейс для доступа к результату конструирования Product (МиниАвто и др.) — продукт Сложный объект, который получается в результате конструирования.

Слайд 64

Описание слайда:

Отношения между участниками Клиент конфигурирует распорядителя (Director) экземпляром конкретного строителя. Распорядитель вызывает методы строителя для конструирования частей продукта. Конкретный строитель создает продукт и следит за его конструированием. Конкретный строитель представляет интерфейс для доступа к продукту.

Слайд 65

Описание слайда:

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

Слайд 66

Описание слайда:

Пример использования паттерна Требуется разработать программный модуль для работы с двумерными массивами действительных чисел. Строки массивов могут иметь различную длину. Цель – преобразование массивов в различные форматы. Например: текстовый файл; XML-файл.

Слайд 67

Описание слайда:

Класс JuggedArray Определим класс JuggedArray (зубчатый массив) с минимальными возможностями нужными для решения поставленной задачи при необходимости интерфейс можно сделать более дружественным.

Слайд 68

Описание слайда:

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

Слайд 69

Описание слайда:

Класса-конвейер JuggedArrayConverter

Слайд 70

Описание слайда:

Класс массива JuggedArray public class JuggedArray { private double [] [] array; public JuggedArray (double [] [] array) // конструктор { this.array = array; } public double this [int row, int col] { // индексатор get {return array[row] [col];} set {array[row][col] = value;} } public int RowCount() { return array.Length; } public int RowSize (int row) { return array[row].Length; } }

Слайд 71

Описание слайда:

Диаграмма классов предложенной реализации

Слайд 72

Описание слайда:

Алгоритм пошагового конвертирования массива Конвертирование массива определим в классе JuggedArrayConverter (класса-строитель) В методе Convert() задается общее описание алгоритма пошагового конвертирования массива выполнение конкретных шагов построения обеспечивает экземпляр класса-строителя. Все методы класса-строителя можно определить как абстрактные нужно учитывать, что при реализации конкретных строителей некоторые из этих методов могут быть не реализованы.

Слайд 73

Описание слайда:

Методы класса JuggedArrayBuilder Почти все методы сделает конкретными, но с пустой реализацией. Определим их как виртуальные (virtual). Абстрактным (без реализации) сделаем только метод Resuit() в связи с необходимостью его реализации в каждом конкретном строителе.

Слайд 74

Описание слайда:

Абстрактный класс-строитель public abstract class JuggedArrayBuilder { public virtual void Initialize () {} public virtual void Start() {} public virtual void StartRow() {} public virtual void Addltem(double item) {} public virtual void FinishRow() {} public virtual void Finish() {} public abstract object Result (); }

Слайд 75

Описание слайда:

Реализация алгоритма конвертирования массива класса JuggedArrayBuilder public object Convert () { builder.Initialize(); // инициализировать построение builder.Start(); // начать построение for (int r = 0; г < this.array.RowCount () ; ++r) { builder.StartRow(); // начать новую строку массив for (int с = 0; с < this.array.RowSize(r); ++c) { builder.Addltern(array[r, c]); // добавить элемент массива } builder.FinishRow(); // завершить строку массива } builder.Finish(); // завершить построение return builder.Result(); // получить результат построения }

Слайд 76

Описание слайда:

Создадим строитель для конвертирования массива в текст Текст потом, например, можно сохранить в текстовый файл. Формат текстового представления отдельные строки массива должны разделяться символом «\n»; элементы строки отделяются между собой пробелом.

Слайд 77

Описание слайда:

Класс TextJuggedArrayBuilder public class TextJuggedArrayBuilder : JuggedArrayBuilder { private StringBuilder text = null; public override void Initialize () { text = new StringBuilder(); } public override void Addltem(double item) { text.Append(item); text.Append(" "} ; } public override void FinishRow() { text.AppendLine(); } public override object Result() { return text; } } // методы Start() и StartRow() не реализованы

Слайд 78

Описание слайда:

Класс XmlJuggedArrayBuilder public class XmlJuggedArrayBuilder : JuggedArrayBuilder { private StringBuilder xml = null; public override void Initialize() { xml = new StringBuilder () ; } public override void Start() { xml.AppendLine(""); xml.AppendLine(""); } public override void StartRow() {xml.AppendLine("");} public override void Addltem(double item) { xml.Append(""); xml.Append(item); xml.Append(""}; xml.AppendLine(); } public override void FinishRow() { xml.AppendLine(""); } public override void Finish() { xml.AppendLine(""); xml.AppendLine(""); } public override object Result() { return xml;} }

Слайд 79

Описание слайда:

Полный вариант диаграммы классов конвертера массивов

Слайд 80

Описание слайда:

Программа - клиент static void Main(string[ ] args) { JuggedArray array = new JuggedArray (// определяем массив new double [ ] [ ] { new double[] {11, 12, 13, 14, 15}, new double[] (21, 22, 23}, new double[] {31, 32, 33, 34} }; // создаем конвертер JuggedArrayConverter converter = new JuggedArrayConverter (); converter.Array = array; // задаем массив Console.WriteLine ( "Текстовое представление массива:") ; // задаем конвертер строителем текстового представления converter.Builder = new TextJuggedArrayBuilder () ; object textArray = converter.Convert (); // проводим конвертацию Console .WriteLine (textArray) ; // выводим результат на консоль Console.WriteLine("Xml-представление массива:") ; // задаем конвертер строителем XML-представления converter.Builder = new XmlJuggedArrayBuilder(); object xmlArray = converter.Convert(); // проводим конвертацию Console.WriteLine(xmlArray); // выводим результат на консоль }

Слайд 81

Описание слайда:

Слайд 82

Описание слайда:

Преимущества шаблона Builder клиентский код не зависит от конкретного строителя; есть возможность определить произвольное число строителей без модификации классов JuggedArray и JuggedArrayConverter.

Слайд 83

Описание слайда:

1.3. Паттерны Singleton (Одиночка) и Monostate (Моносостояние) Обычно между классами и их объектами существует отношение один-ко-многим, можно создавать много экземпляров одного класса. Объекты создаются, когда они требуются, и уничтожаются, когда перестают быть необходимыми. Однако у некоторых классов должен быть только один объект. создается в начале работы программы уничтожен при ее завершении. Такие объекты могут быть: корневыми объектами приложения – из них можно добраться до других объектов системы. фабриками, порождающими другие объекты. менеджерами, которые следят за другими объектами.

Слайд 84

Описание слайда:

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

Слайд 85

Описание слайда:

Может показаться, что вводить специальные механизмы обеспечения единственности таких объектов – излишество. В конце концов, на этапе инициализации приложения можно просто создать по одному экземпляру каждого, и дело с концом. Такой шаблон иногда называется «Просто создай одного».

Слайд 86

Описание слайда:

Паттерн Одиночка (Singleton) Одиночка (Singleton) – очень простой паттерн. public class Singleton { private static Singleton theInstance = null; private Singleton() {} public static Singleton Instance { get { if (theInstance == null) theInstance = new Singleton(); theInstance; } } }

Слайд 87

Описание слайда:

Реализация класса Singleton public class Singleton { private static Singleton theInstance = null; private Singleton() {} public static Singleton Instance { get { if (theInstance == null) theInstance = new Singleton(); theInstance; } } }

Слайд 88

Описание слайда:

Пример класса Описание класса public class Singleton{ private static Singleton instance; private Singleton() { } public static Singleton Instance { get { if (instance == null) {instance = new Singleton(); } return instance; } } public String DataItem { get; set; } } Использование класса Singleton single = Singleton.Instance; single.DataItem = "value";

Слайд 89

Описание слайда:

Достоинства Применимость к любому классу. Любой класс можно преобразовать в Одиночку, если сделать его конструкторы закрытыми и добавить соответствующие статические методы и переменную-член. Может быть создан путем наследования. Имея некоторый класс, можно создать его подкласс, который будет Одиночкой. Отложенное вычисление. Если Одиночка не используется, то он и не создается.

Слайд 90

Описание слайда:

Недостатки Уничтожение не определено. Не существует приемлемого способа уничтожить или «списать» Одиночку. Даже если добавить метод, обнуляющий переменную theInstance, другие модули могут хранить у себя ссылку на Одиночку. При последующих обращениях к Instance будет создан новый экземпляр, что приведет к образованию двух одновременно существующих экземпляров. Эта проблема особенно остро стоит в языке C++, где экземпляр может быть уничтожен, что приведет к разыменованию уже не существующего объекта. Не наследуется. Класс, производный от Одиночки, сам не является Одиночкой. Если необходимо, чтобы он был Одиночкой, придется добавить статический метод и переменную-член. Эффективность. Каждое обращение к свойству Instance приводит к выполнению предложения if. Для большинства обращений это предложение бесполезно. Непрозрачность. Пользователи Одиночки знают, с чем имеют дело, потому что вынуждены обращаться к свойству Instance.

Слайд 91

Описание слайда:

Пример использования шаблона Одиночка Предположим, что имеется веб-приложение, позволяющее пользователям входить в защищенные области сервера. В таком приложении будет какая-то БД, которая содержит описания пользователей: имена, пароли другие атрибуты. Доступ к базе данных выполняется с помощью специального API.

Слайд 92

Описание слайда:

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

Слайд 93

Описание слайда:

Лучше воспользоваться паттерном Façade (Фасад) и создать класс UserDatabase, предоставляющий методы для чтения и изменения объектов User. Это частный случай шаблона Фасад , называемый шаблоном Шлюз (Gateway). Методы обращаются к стороннему API доступа к базе данных, осуществляя отображение между объектами User и таблицами базы. Внутри класса UserDatabase можно обеспечить соглашения о структуре и порядке доступа. Например, можно гарантировать, что не будет добавлена запись User, в которой поле username пусто. Или упорядочить обращения к записи User, так, чтобы никакие два модуля не могли одновременно читать и изменять ее.

Слайд 94

Описание слайда:

Решение на основе паттерна Singleton (Одиночка) Создается класс с именем UserDatabaseSource, который реализует интерфейс UserDatabase. В коде свойства Instance нет традиционного предложения if, защищающего от многократного создания. Вместо этого используется механизм статической инициализации, имеющийся в .NET.

Слайд 95

Описание слайда:

Интерфейс UserDatabase и класс UserDatabaseSource public interface UserDatabase { User ReadUser(string userName); void WriteUser(User user); } public class UserDatabaseSource : UserDatabase { private static UserDatabase theInstance = new UserDatabaseSource(); public static UserDatabase Instance { get { return theInstance; } } private UserDatabaseSource() { } public User ReadUser(string userName) { // Реализация } public void WriteUser(User user) { // Реализация } }

Слайд 96

Описание слайда:

Такое использование паттерна Одиночка распространено чрезвычайно широко. Гарантируется, что весь доступ к базе данных производится через единственный экземпляр UserDatabaseSource. При этом в UserDatabaseSource очень легко вставлять различные проверки, счетчики блокировки, которые обеспечивают выполнение требуемых соглашений о порядке доступа и структуре кода.

Слайд 97

Описание слайда:

Паттерн Monostate (Моносостояние ) Паттерн Monostate (Моносостояние) предлагает другой способ обеспечения единственности. public class Monostate { private static int itsX; public int X { get { return itsX; } set { itsX = value; } } }

Слайд 98

Описание слайда:

Тесты для проверки using NUnit.Framework; [TestFixture] public class TestMonostate { [Test] public void TestInstance() { Monostate m = new Monostate(); for (int x = 0; x < 10; x++) { m.X = x; Assert.AreEqual(x, m.X); } }

Слайд 99

Описание слайда:

Если заменить в этих тестах все предложения new Monostate на вызовами Singleton.Instance, то тесты все равно прошли бы успешно. Таким образом, тесты описывают поведение Одиночки, не налагая ограничения на единственность экземпляра! Каким образом два экземпляра могут вести себя так, будто это единственный объект? Да просто это означает, что у них одни и те же переменные-члены. А добиться этого можно, сделав все переменные-члены статическими.

Слайд 100

Описание слайда:

Реализация класса Monostate public class Monostate { private static int itsX; public int X { get { return itsX; } set { itsX = value; } } }

Слайд 101

Описание слайда:

Слайд 102

Описание слайда:

Описание класса public class Monostate { private static string dataItem; public string DataItem { get { return dataItem; } set { dataItem = value; } } public Monostate() { } } Использование класса var single = new Monostate(); single.DataItem = "value";

Слайд 103

Описание слайда:

Сколько бы экземпляров класса Monostate ни создать, все они ведут себя так, как будто являются одним и тем же объектом. Можно даже уничтожить все текущие экземпляры, не потеряв при этом данных. Различие между паттернами Singleton и Monostate – это различие между поведением и структурой.

Слайд 104

Описание слайда:

Паттерн Singleton навязывает структуру единственности, не позволяя создать более одного экземпляра. Паттерн Monostate, напротив, навязывает поведение единственности, не налагая структурных ограничений. Это различие станет понятным, если заметить, тесты для паттерна Monostate проходят и для класса Singleton, однако у класса Monostate нет ни малейшей надежды пройти тесты для Singleton.

Слайд 105

Описание слайда:

Достоинства Прозрачность – пользователь работает точно так же, как с обычным объектом, ничего не зная о том, что это «моносостояние». Допускает наследование. Подклассы моносостояния также обладают этим свойством. Более того, все его подклассы являются частями одного и того же моносостояния, так как разделяют одни и те же статические переменные-члены. Полиморфизм Т.к. методы моносостояния не статические, их можно переопределять в производных классах. Т.е. подклассы могут реализовывать различное поведение при одном и том же наборе статических переменных-членов. Точно определенные моменты создания и уничтожения. Т.к. переменные-члены моносостояния статические, то моменты их создания и уничтожения точно определены.

Слайд 106

Описание слайда:

Недостатки Невозможность преобразования. Класс, не являющийся моносостоянием, невозможно превратить в моносостояние с помощью наследования. Эффективность. Будучи настоящим объектом, моносостояние может многократно создаваться и уничтожаться. Иногда это обходится дорого. Постоянное присутствие. Переменные-члены моносостояния занимают место в памяти, даже если объект никогда не используется. Локальность. Паттерн Моносостояние не может гарантировать единственность в нескольких экземплярах CLR или на нескольких компьютерах.

Слайд 107

Описание слайда:

Пример использования паттерна Monostate Рассмотрим реализацию простого конечного автомата (КА), описывающего работу турникета в метро . Первоначально турникет находится в состоянии Locked (Закрыт). Если опустить монету, турникет перейдет в состояние Unlocked, откроет дверцы, сбросит сигнал тревоги (если он был включен) и поместит монету в монетоприемник. Если в этот момент пользователь пройдет через турникет, тот вернется в состояние Locked и закроет дверцы.

Слайд 108

Описание слайда:

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

Слайд 109

Описание слайда:

Слайд 110

Описание слайда:

Реализация моносостояния Turnstile public class Turnstile { private static bool isLocked = true; private static bool isAlarming = false; private static int itsCoins = 0; private static int itsRefunds = 0; protected static readonly Turnstile LOCKED = new Locked(); protected static readonly Turnstile UNLOCKED = new Unlocked(); protected static Turnstile itsState = LOCKED; public void reset() { Lock(true); Alarm(false); itsCoins = 0; itsRefunds = 0; itsState = LOCKED; } public bool Locked() { return isLocked; } public bool Alarm() { return isAlarming; } public virtual void Coin() { itsState.Coin(); } public virtual void Pass() { itsState.Pass(); } protected void Lock(bool shouldLock) { isLocked = shouldLock; } protected void Alarm(bool shouldAlarm) { isAlarming = shouldAlarm; } public int Coins { get { return itsCoins; } }

Слайд 111

Описание слайда:

Слайд 112

Описание слайда:

Полезные особенности паттерна Monostate (Моносостояние) Использованы возможность создавать полиморфные подклассы и то, что подклассы сами являются моносостояниями. Кроме того, видно, насколько трудно бывает превратить объект-моносостояние в объект, таковым не являющийся. Структура решения существенно опирается на то, что Turnstile – моносостояние. Если бы потребуется применить этот КА к управлению несколькими турникетами, код придется сильно переработать.

Слайд 113

Описание слайда:

Полезные особенности паттерна Monostate (Моносостояние) Может возникнуть вопрос в связи с необычным использованием наследования в этом примере. То, что классы Unlocked и Locked сделаны производными от Turnstile, представляется нарушением принципов ООП. Но поскольку Turnstile – моносостояние, то не существует его отдельных экземпляров. Поэтому Unlocked и Locked – это не самостоятельные классы, а части абстракции Turnstile. Они имеют доступ к тем же переменным и методам, что и Turnstile.

Слайд 114

Описание слайда:

Выводы по шаблонам Singleton и Monostate Часто бывает необходимо обеспечить единственность объекта некоторого класса. Шаблоны Singleton и Monostate принципиально различным способом решают эту задачу. Паттерн Singleton опирается на использование закрытых конструкторов, статической переменной-члена и статического метода, которые совместно ограничивают количество создаваемых экземпляров. В паттерне Monostate все переменные-члены просто сделаны статическими.

Слайд 115

Описание слайда:

Выводы по шаблонам Singleton и Monostate (2) Шаблон Singleton лучше применять, когда уже есть некоторый класс и тогда обеспечить единственность экземпляра можно, создав его подкласс, если не против обращения к свойству Instance для получения доступа к этому экземпляру. Шаблон Monostate удобнее когда единичный объект класса желательно сделать незаметным для пользователей или когда необходимо полиморфное поведение единственного объекта.