Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Сильный искусственный интеллект и объектно-ориентированное программирование синтез парадигм
.pdf
контексте ситуаций результат взаимодействия системы со средой преодолевает порог всех прошлых состояний контекста
и возникает нечто качественно новое в рамках системы, которая
в дальнейшем запускает процесс трансформации среды реализации потенциала. В несколько абстрактном смысле – это «рецепт» создания системы сильного ИИ, в котором опыт паттерна
«Одиночка» обязательно будет заложен в самое основание.
Выводы по главе 11
Так как в контексте нашего исследования в первую очередь
обращается внимание на целесообразность использования ключевых, абстрагированных аспектов любого отдельно взятого
ПП в контексте разработки систем сильного ИИ, то и выводы
будут формулироваться нами в соответствующем ключе, с существенно смещенным ракурсом рассмотрения проблематики
со сферы промышленного программирования на нужды построения «разумных» систем в том смысле, в котором их определял
Джон Сёрл. В данном контексте порождающие ПП не только позволяют заложить основу для создания ПК в рамках системы
и далее поддерживать «рождаемость» на уровне, необходимом
и достаточном для эффективного функционирования системы
в целом, но и несут в себе, можно так сказать, уточнение способов наиболее продуктивного создания ПК. Мы, в рамках исследования, стараемся делать наибольший акцент на некотором
обобщении любой конкретики, что и было наглядно показано
в данной главе, а потому стараемся по возможности избегать деталей конкретных реализаций и концептуально формировать
максимально «свободные» условия для развития интеллектуальных систем. Поэтому на основе той конкретики, которая
была нами исследована в порождающих ПП, мы вынесли только
лишь границы – верхнюю и нижнюю. Верхняя граница условно
означает предел возможностей реализации, а нижняя – то, что
должно присутствовать в формирующейся интеллектуальной
системе в любом случае, так как оно крайне удобно и целесооб-
161
разно. И порождающие ПП предоставляют достаточное количество подобного «материала».
«Абстрактная фабрика», как выяснилось, отлично иллюстрирует зарождение сначала целостной психики человека на
биологической основе его мозга (в узком смысле) и тела (в широком смысле), а затем порождение уже самой психикой сложных
психических феноменов, определяемых как конкретные продукты, такие как концептуальное мышление, реализация сложных
поведенческих паттернов и т. д. Таким образом, предполагается,
что и в контексте разработки человекоразмерных интеллектуальных систем применение данного паттерна может привести
к возникновению феномена технотропного сознания.
«Фабричный метод» предоставляет множество базовых «заготовок» для реализации крайне широкого спектра различных
активностей, заготовок, в каждую из которых изначально заложен весьма обширный потенциал, проявляющийся ситуативно,
в зависимости от контекста, и позволяющий системе действовать
с максимальной эффективностью в любой возникающей ситуации.
Паттерн «Строитель» представляет к рассмотрению очень
перспективную абстракцию, по сути являющуюся неким «вечным двигателем», вырванным из контекста очень мощным
и автономным процессом построения составных структур.
«Строитель» вполне способен претендовать на роль «сердца» высокоинтеллектуальной системы по той причине, что именно его
смысл может стать если и не искомой «искрой самоорганизации», то тем самым «огнем», который поддерживает горение,
т. е. автономное функционирование системы сильного ИИ.
Паттерн «Прототип» позволит осуществлять репликацию ПК,
так как именно в этом и заключается основная его идея. Путем
выявления наиболее значимых аспектов некоего компонента
и заключения этих аспектов как содержания в определенную
форму создается прототип – некая способная к самовоспроизведению программная сущность. Точно таким же образом, как
и в макромире, программная система должна быть способной
к воспроизведению себе подобных, и «Прототип» позволяет это
осуществить.
162
Паттерн «Одиночка», в свою очередь, может оказаться способным обеспечить тот самый качественный самоорганизационный скачок от неупорядоченности к относительно стройной
и организованной системе, так как абстрагированная суть данного паттерна сводится к однократному порождению ПК качественно нового типа и, в связи с этим, последующей трансформацией всего контекста.
Как видно из вышесказанного, порождающие паттерны являются крайне значимыми в контексте разработки систем сильного ИИ, так как аккумулируют в себе многие фундаментальные аспекты жизни в целом, облекают их в форму паттерна
и резюмируют в некоторой последовательности действий. Соответственно, нам представляется весьма целесообразным использование порождающих паттернов в проектировании систем
сильного ИИ.
Глава 12
ПОВЕДЕНЧЕСКИЕ ПАТТЕРНЫ ООП
Поведенческие ПП, как и следует из названия, ответственны
за реализацию поведения ПК. Их ответственность сосредоточена в основном на взаимодействии между ПК в рамках отдельной
системы. В Design patterns указывается: «Паттерны поведения
связаны с алгоритмами и распределением обязанностей между
объектами. Речь в них идет не только о самих объектах и классах, но и о типичных схемах взаимодействия между ними. Паттерны поведения характеризуют сложный поток управления,
который трудно проследить во время выполнения программы.
Внимание акцентируется не на схеме управления как таковой,
а на связях между объектами» [114, с. 216]. Как следует из вышесказанного, помимо непосредственно паттернов в их классическом виде также еще наличествуют «типичные схемы взаимодействия», т. е. можно сказать, что существуют паттерны,
в абстрактный каркас которых заложены схемы взаимодействия
между другими паттернами. Мы определяли паттерн наиболее
формально (т. е. с наибольшим превалированием формы над содержанием) следующим образом: паттерн – это абстракция как
целое, состоящая из абстракций как частей и заключающая
в себе образ действия, направленный на решение какой-либо задачи в определенном контексте. Некоторый образ действия, соответственно, есть неотъемлемая часть сущности любого паттерна, заложенный в самое его ядро. Здесь же эта особенность
выводится на несколько иной уровень. А именно, мы имеем дело
не просто с целостной абстракцией, состоящей из «подабстракций» и каким-то образом реализовывающей свое предназначение.
Теперь у нас наличествуют целостные абстракции, состоящие
164
из «подабстракций» и заключающие в своем образе действия
общий механизм управления другими, по уровню себе подобными или сколько-то более низкими, абстракциями. Как можно
заметить, ситуация непростая.
Как мы и говорили ранее о связях между паттерном и алгоритмом, алгоритмы используются «внутри», «под капотом» паттернов и являют собой тот самый инструментарий, благодаря
которому паттерн успешно достигает цели, реализуя тем самым
смысл своего существования (смысл существования паттерна –
успешное достижение цели). Т. е. алгоритм по отношению
к паттерну – это примерно то же самое, что отбойный молоток
по отношению к строительному рабочему или удар по отношению к боксеру. И в рамках данной части нашего исследования
мы близко и достаточно наглядно с этим ознакомимся. Также
следует отметить, что поведенческие паттерны не являются менее
фундаментальными по отношению к паттернам порождающим.
Не являются они и более конкретными или менее абстрактными. Дело скорее в том, что после того, как созданы необходимые
ПК в рамках отдельной системы за счет функционирования порождающих паттернов, необходимо заставить эти компоненты
реализовывать свое предназначение путем балансировки соответствующих ответственностей между ними. Причем эта балансировка осуществляется методом предварительной настройки
и последующей координации в зависимости от текущей ситуации в контексте функционирования системы. Таким образом,
поведенческие паттерны являют собой ПК, которые ответственны за осуществление динамичной связи между другими ПК,
обеспечивая тем самым эффективное функционирование системы в целом.
Группа поведенческих паттернов самая многочисленная и в нее
включены одиннадцать паттернов:
«Хранитель»
«Цепочка обязанностей»
«Наблюдатель»
«Состояние»
«Команда»
165
«Интерпретатор»
«Стратегия»
«Итератор»
«Шаблонный метод»
«Посредник»
«Посетитель»
12.1. Поведенческий паттерн «Хранитель»
Идентификатор. Хранитель (Memento).
Классические элементы. Хранитель, хозяин, посыльный.
Назначение. Фиксация и сохранение внутреннего состояния
ПК с той целью, чтобы при необходимости предоставлять возможность воспроизвести его в нужном состоянии.
Проблема. «Хранитель» применяется в тех случаях, в которых необходимо тем или иным образом зафиксировать внутреннее
состояние ПК для того, чтобы при необходимости предоставлять возможность восстановить ПК в том состоянии, в котором
он изначально был зафиксирован. К примеру, паттерн «Хранитель» применяется при пробных трансформациях некой программной сущности, при которых необходимо зафиксировать ее
статус для наличия возможности восстановления этой сущности в изначальном зафиксированном статусе. Также при осуществлении компонентом некоторой деятельности и изменении
вследствие этого состояния компонента может возникнуть необходимость вернуть его в исходное состояние для осуществления
этой же деятельности в дальнейшем – дабы не пересоздавать компонент каждый раз заново.
Концептуальное решение. Необходимость зафиксировать
все особенности ПК, дабы привести его к необходимому состоянию, не кажется сложным мероприятием, но так только на первый взгляд. На самом деле, как мы помним, в рамках ООП наличествует незыблемая специфическая особенность, являющаяся
одним из ключевых аспектов – инкапсуляция, т. е., по сути, сокрытие всех особенностей ПК, специально не предназначенных
для взаимодействия с другими компонентами. Опять же, как
166
уже ранее упоминалось, любому ПК в рамках системы доступен
только лишь интерфейс других компонентов и ничего более, так
как иной вариант вполне мог бы превратить всю систему в небезопасную. И вариантом решения данной проблемы становится
паттерн «Хранитель». Как указывается в Design patterns: «…хранитель – это объект, в котором сохраняется внутрен нее состояние
другого объекта – хозяина хранителя» [114, с. 331]. Если несколько обобщить смысл, то формируется ситуация, в рамках которой один ПК (хозяин) создает себе в помощь еще один компонент (хранитель), в котором при необходимости сохраняет свое
текущее состояние. Доступ к хранителю наличествует только
у хозяина. Посыльный же – это третий ПК, выступающий в роли
«потребителя состояний». Он делает запрос к первому компоненту на получение второго. После получения он воспроизводит
сам или передает компонент хозяина в необходимом и требуемом состоянии, после чего отдает хранителя обратно хозяину.
У посыльного нет доступа к состоянию хранителя, а есть лишь
право восстановления хозяина в нужном состоянии без получения полной информации о нем. Итог: объект восстановлен, инкапсуляция не нарушена.
Предполагаемые результаты и преимущества. Высокая эко
номичность функционирования системы в плане отсутствия необходимости повторного создания уже ранее создававшихся ПК,
которые были тем или иным образом трансформированы. Возможность легко при необходимости вернуться к ранее существовавшим версиям ПК, возможность сбросить все изменения
и тому подобные варианты. Отсутствие опасного нарушения инкапсуляции.
Гипотетический пример реализации паттерна. Наличе-
ствует реальный крайне часто применяемый на практике пример
реализации данного паттерна в среде разработки программного
обеспечения – системы контроля версий, наиболее известной из
которых является Git, на основе которого был создан Github,
являющийся удаленным хранилищем версий. Работает это все
следующим образом. В некоторой базе данных сохраняется изначальное состояние системы. Затем все вносимые в нее измене-
167
ния также последовательно сохраняются. Соответственно, если
необходимо по какой-то причине вернуться к какому-либо этапу, то это крайне легко реализовать.
Осмысление структуры паттерна. Структура данного паттерна довольно сложна, если вникнуть в суть. Т. е. на начальном
этапе хозяин создает хранителя, дабы сложить с себя ответственность за сохранение своего состояния и делегировать данный функционал своему подкомпоненту. Это отношение по типу делегирования. С другой стороны, так как именно хозяин
и создает хранителя, то вполне логично предположить, что хранитель не существовал бы без хозяина – это означает, что хозяин
связан с хранителем по типу агрегации (он бы существовал и без
хранителя), а хранитель связан с хозяином по типу композиции
(он бы без хозяина не существовал, так как не было бы смысла
в его существовании). Посыльный здесь представлен как бы объ-
ектом «со стороны», что означает, что его взаимодействие с хозяином может быть произвольного типа, а его взаимодействие
с хранителем примерно напоминает обоюдостороннее агрегирование. Далее, после того как хранитель уже функционирует
и передан посыльному, ситуация несколько трансформируется
в том смысле, что именно за счет взаимодействия посыльного
с хранителем хозяин получает право на дальнейшее функционирование. Т. е. теперь уже хозяин связан с хранителем по типу
композиции, так как он, не будь хранителя, не смог бы продолжить дальнейшее существование. Ровно так же и с посыльным.
В общем смысле стоит отметить, что динамика взаимосвязей
в рамках паттерна довольно высока.
Значимость паттерна в контексте разработки систем
сильного ИИ. В контексте разработки систем сильного ИИ ПК,
который, по сути, является буквальным воплощением памяти,
разумеется, необходим. Учет негативного или позитивного опыта предыдущих действий нужен для адекватного планирования
и формирования действий последующих и корректной оценки
действий актуальных. Наличие возможности возврата к прежним
состояниям вместе с извлечением полезного опыта из трансформированного состояния представляет собой, в случае с, допу-
168
стим, человеком, некоторую внутреннюю работу, напоминающую самоанализ. Дело в том, что возврат к прежним состояниям
должен иметь причины и если он происходит, значит, причины
есть. Собственно говоря, если аппаратно-программная система
с претензией на наличие интеллектуальной активности вдруг
решит заняться самоанализом, то сильный ИИ состоится в тот
же момент. Поэтому такой ценный опыт, как контроль версий
с возможностью возврата, необходимо закладывать как потенциальную возможность.
12.2. Поведенческий паттерн «Цепочка обязанностей»
Идентификатор. Цепочка обязанностей (Chain of responsi-
bility).
Классические элементы. Обработчик, конкретный обра-
ботчик.
Назначение. Осуществление обработки некоторых запросов
в тех случаях, в которых заранее неизвестно, какому именно ПК
из некоторого их множества придется обработать пришедший
запрос.
Проблема. Предположим, что существует некоторая программная система, в которой наличествует определенное количество входных точек. Каждая из этих входных точек (возможно)
связана со своими «подточками». Эти «подточки» совершенно
необязательно связаны отношениями наследования – это могут
быть вполне равнозначные точки единого уровня абстракции.
Каждая точка представляет собой определенный ПК, и каждый
из этих компонентов содержит в себе условный ответ на некоторый вопрос. В данную систему на некоторую из этих точек приходит определенный вопрос. Никогда заранее неизвестно, содержит ли ПК, к которому пришел запрос подобного типа, ответ на
этот вопрос. Вопрошающему (дополнительный элемент паттерна
«Клиент») неизвестно, к какой именно из этих точек адресован
его конкретный запрос. Более того, после совершения запроса
и разрешения адресации вопрошающий становится привязан
к конкретной точке (нарушение принципа слабого зацепления
169
и снижение эластичности системы). Соответственно, попытки
обращаться к системе с такой организацией напоминают тычки
пальцем в небо или поиск иголки в стоге сена. Разумеется, подобная проблема требует некоторого решения, и этим решением
выступает паттерн «Цепочка обязанностей», который, как указывается в Design patterns, «позволяет избежать привязки отправителя запроса к его получателю, предоставляя возможность
обработать запрос нескольким объектам. Связывает объектыполучатели в цепочку и передает запрос по этой цепочке, пока
он не будет обработан» [114, с. 217].
Концептуальное решение. Система с ограниченным коли-
чеством конечных точек, каждая из которых представляет собой
обработчик. Каждый из этих компонентов имеет доступ к некоторому множеству иных компонентов (конкретных обработчи-
ков) по ассоциативной, логически обоснованной связи. Опять же,
каждый из этих компонентов содержит в себе ответ на некоторый запрос (связь вопроса с ответом похожа на связь по типу key –
value, т. е. ключ – значение) в том смысле, что каждый из этих
компонентов (включая самый первый – обработчик) исследует
пришедший запрос на предмет его соответствия своему «ключу», и если «ключи» совпадают, то компонент отвечает на запрос лично сам, а в случае несовпадения компонент передает
запрос дальше по ассоциативной цепочке, если у него имеется
на это возможность в плане наличия дальнейших конкретных
обработчиков. Если же у компонента и «ключи» не совпадают,
и дальнейшие конкретные обработчики отсутствуют, то запрос,
как это называется, теряется, т. е. остается без ответа.
Предполагаемые результаты и преимущества. Отсутству-
ет прямая привязка вопрошающего к обработчику, что не толь-
ко соответствует принципу слабого зацепления, но и делает систему гораздо более эластичной. Позволяет с довольно высокой
вероятностью получить ответ на запрос в случае его фактического наличия, причем осуществить поиск ответа при необходимости до весьма глубокого уровня.
Гипотетический пример реализации паттерна. Ранее в качестве примера реализации одного из паттернов («Одиночки»)
170
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]