Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Сильный искусственный интеллект и объектно-ориентированное программирование синтез парадигм
.pdf
контекст, а в случае с паттерном – всегда «ожидаемые», «планируемые», «прогнозируемые» и никогда не гарантированные. Уже
упоминалось, что так происходит ввиду сущностных различий
между феноменами паттерна и алгоритма: алгоритм всегда конкретен, а паттерн всегда до определенной степени абстрактен.
Мы же, в контексте нашего исследования, будем опираться
на своеобразный шаблон исследования и осмысления паттерна,
некоторую, можно выразиться, карточку паттерна, которая состоит из девяти ключевых пунктов:
Идентификатор. Имя паттерна, привязанное к его значению.
Классические элементы. Составляющие паттерна, которые,
как правило, признаются обязательными.
Назначение. Для достижения каких целей предназначен
паттерн.
Проблема. Какие проблемы решает паттерн.
Концептуальное решение. Описание паттерна.
Предполагаемые результаты и преимущества. Позитивные
ожидания от использования паттерна.
Гипотетический пример реализации паттерна. Пример реализации паттерна в вариабельном контексте.
Осмысление структуры паттерна. Связи элементов паттерна
друг с другом.
Значимость паттерна в контексте разработки систем сильного ИИ. Выявление ключевых абстрактных особенностей паттерна, которые предположительно способны оказаться значимыми
для сферы построения сильного ИИ.
Выводы по главе 10
На основе проведенного исследования мы пришли к выводу,
что шаблон, алгоритм и паттерн являются различными понятиями по причине сущностной разницы между ними. Паттерны
мы определили как выявленные закономерности последовательности действий в каком-либо контексте, направленные на решение некоторой задачи, имеющей один или более вариантов решения. Шаблон был нами определен как некоторый эталон, по
«образу и подобию» которого создаются определенные «изде-
141
лия» со степенью отличия от эталона в строго ограниченных
рамках по контексту и вариантам. Под алгоритмом же мы условились понимать набор последовательных действий, направленных
на решение какой-либо задачи за определенное конечное время.
Было показано, что основное отличие алгоритма от паттерна
заключается в том, что алгоритм всегда обладает крайне четко
очерченной структурой и не допускает вариаций ее трансформирования, а также всегда дает гарантированный результат,
и, более того, всегда возвращает одинаковые выходные данные
при одинаковых входных данных. Структура паттерна же вариативна и может трансформироваться в зависимости от контекста.
А также применение паттерна никогда не может гарантировать
результат, и паттерн не является четкой последовательностью
конкретных действий, так как он по своей сути абстрактен и обладает больше формой, чем содержанием, т. е. паттерн – это
скорее совокупность абстрактных образов действия, чем непосредственно конкретики. Также было продемонстрировано, что
к шаблону паттерн и алгоритм, по сути, отношения не имеют,
так как шаблон, являясь просто неким эталоном, к которому
нужно стремиться, абсолютно индифферентен к способам его
«достижения».
Далее исследована генеалогия паттернов ООП и указано, что
их истоки ведут к ПП городских зданий, что само по себе подтверждает фундаментальность и всеобщность паттернов в целом. Также было указано на то, что паттерны ООП вполне могут
быть экстраполированы в контекст функционального программирования с некоторыми их «адаптациями». Были освещены
GoF-паттерны и указано, что данные паттерны являются классическими для ООП и, как правило, ассоциируются с паттернами ООП вообще.
Уточнена специфика нашего исследования ПП, ПК, связей
между ними и их структурами. Специфика заключается в выявлении ключевых деталей и максимально возможном абстрагировании сути любого феномена. Также было указано на классический шаблон рассмотрения ПП и разработан наш собственный
шаблон их исследования.
Глава 11
ПОРОЖДАЮЩИЕ ПАТТЕРНЫ ООП
Паттерны из группы порождающих, как и следует из названия группы, ответственны за создание новых ПК. Паттерны
этой группы отличаются двумя ключевыми характеристиками:
они содержат информацию о функционале определенных ПК,
характерных для конкретной системы, т. е. в некотором роде
определяют грани возможного-невозможного; они не раскрывают подробностей реализации своей функциональности, так как
она, разумеется, инкапсулирована.
Как указывают сами авторы Design patterns, говоря о специфике функционирования порождающих паттернов: «Единственная информация об объектах, известная системе, – это их
интерфейсы, определенные с помощью абстрактных классов.
Следовательно, порождающие паттерны обеспечивают большую
гибкость в отношении того, что создается, кто это создает, как
и когда» [114, с. 89].
Здесь стоит отдельно сказать о том, что собой представляет
только что упомянутый в цитате абстрактный класс, так как этот
феномен ООП крайне значим в контексте построения систем
сильного ИИ. Разумеется, абстракция сама по себе, как понятийная сущность, возводящая в абсолют превалирование формы
над содержанием, допускает достаточно широкое толкование,
и все ее подсущности, ответвления и экземпляры отличаются
этим же качеством. Поэтому помимо нашего определения возможны и иные. Мы же определяем абстрактный класс как наиболее высокоуровневый способ описания сущности в контексте
ООП, отличающийся тем, что он не определяет конкретную реализацию своих методов, лишь обозначая их, а также не создает
143
экземпляров. От абстрактного класса можно лишь наследоваться
другим классам, а затем непосредственно реализовывать его –
абстрактного класса – функционал, и только лишь после этого
возможным становится создавать экземпляры, т. е. сами объекты, воплощающие локально, «на местах», тот функционал, основа которого была изначально обобщенно и «высокоуровнево»
заложена и окаймлена уже в рамках абстрактного класса. По
сути, абстрактный класс лишь задает константы и определяет
«законы физики» в рамках конкретной программной системы.
В случае с данным феноменом, как можно заметить, напрашиваются некоторые параллели с предлагаемым нами и формально охарактеризованным ранее решением – созданием системы, в рамках которой не реализуется конкретный функционал,
а лишь определяются «грани реальности» и все зависимости
сводятся к зависимости только от абстракций. Но так как феномен абстрактного класса в ООП существует, а сильный ИИ на
данный момент принципиально не существует, очевидно, что
чего-то не хватает. Однако феномен абстрактного класса, точнее
присущую ему идею – реализацию самой сути абстракции на
допустимо конкретном уровне – не стоит сбрасывать со счетов
только по причине актуального отсутствия сильного ИИ. Вполне вероятно, что в данном контексте просто отсутствует механизм запуска конкретного и необходимого для создания системы сильного ИИ процесса, а также возможно, что феномен
абстрактного класса реализуется в рамках паттернов или групп
паттернов, не соответствующих необходимостям создания систем сильного ИИ.
В любом случае при помощи функционала порождающих
паттернов в программной системе происходит примерно следующее: создаются некоторые ПК с определенным интерфейсом
и этот интерфейс – все, что известно о них всей остальной системе.
Их, созданных при помощи порождающих паттернов ПК, генеалогические и онтологические аспекты, конечно же, инкапсулированы непосредственно в функционал этих самых порождающих
паттернов. Подобный контекст в рамках программной системы
примерно подобен смоделированной ситуации в рамках пара-
144
дигмы сильного ИИ, при которой система сильного ИИ уже непосредственно наличествует и функционирует, но ни о генеалогических его аспектах, ни об онтологическом его статусе мы
ничего не только не знаем, но и априори не способны узнать.
Также это несколько напоминает ситуацию с уже реально наличествующим человеческим сознанием: мы взаимодействуем с его
интерфейсом и это, по крайней мере на данный момент, есть
предел наших возможностей – не существует единого мнения
ни на тему его происхождения, ни на тему его сущностных характеристик.
Из этого следует, что тенденция к естественности и приближенности к реалиям макромира в контексте ООП сохраняется,
как мы и постулировали ранее. На данном этапе уже становится
понятно, почему это так: будь оно иначе в ООП – на примере
паттерна – паттерны бы не смогли «выжить». Не следует забывать,
что паттерны не есть некое искусственное образование (сильный ИИ тоже, к слову сказать, лишь называется «искусственный», а подразумевается «альтернативный» или «другой», «нечеловеческий»), напротив, паттерны есть выявленные успешные
последовательные действия в каком-либо контексте, направленные на решение какой-либо задачи. Т. е. это (как и все составляющие ООП) – некий успешный продукт макромира, «победитель»
в своем контексте. А ООП, подобно нейролингвистическому
программированию (которое, конечно, не является написанием
компьютерных программ), просто аккумулирует в себе таких
«победителей».
Также помимо естественности мы отметили стремление
к сокрытию функционала, который в рамках разработки программных систем оправдан безопасностью: отсутствует возможность переопределения методов высокоуровневых классов,
что само по себе, как наличествующая в контексте возможность,
может нарушить функционирование системы в целом. Причиной является тот факт, что порождающие паттерны – это высокоуровневые феномены, т. е. абстрактные, имеющие больше
формы, чем содержания, и, соответственно, им заранее не может
быть известно, какое именно содержание понадобится им для
145
заполнения этой самой формы в определенный момент, при решении какой-либо конкретной задачи и в некотором определенном контексте, однако заранее известно, что быть может и чего
не может быть. Ну и, разумеется, для эффективного функционирования в зоне своей ответственности основной потенциал ПК
должен быть инкапсулирован, в полном соответствии с ключевыми аспектами парадигмы ООП.
К группе порождающих относят пять паттернов:
«Абстрактная фабрика»
«Фабричный метод»
«Строитель»
«Прототип»
«Одиночка»
11.1. Порождающий паттерн «Абстрактная фабрика»
Идентификатор. Абстрактная фабрика (Abstract factory).
Классические элементы. Абстрактная фабрика, конкретная
фабрика, абстрактный продукт, конкретный продукт, клиент.
Назначение. Создание ПК, объединенных некоторой ассо-
циацией в общем смысле. Как указывается в Design patterns,
«Абстрактная фабрика» «предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов,
не специфицируя их конкретных классов» [114, с. 93].
Проблема. Необходимость наличия в системе некоего центрального узла, ответственного за создание ПК, в качестве ответов на возникающие в рамках системы потребности. Детерминанты этого в том, что спектр возникающих потребностей
достаточно широк, ситуации их возникновения весьма обширны и заранее точно что-либо спрогнозировать, как правило, затруднительно.
Концептуальное решение. Создание абстрактного класса со
способностью порождать так называемые конкретные классы,
т. е. стандартные классы с конкретной спецификой реализации
их функционала, при запросе на их существование в контексте
системы. Таких классов в рамках данного паттерна создается два:
абстрактная фабрика и абстрактный продукт.
146
Предполагаемые результаты и преимущества. Высокая
эластичность системы, т. е. способность системы гибко реагировать на возникающие потребности и создавать полноценные обработчики входящих запросов и ответов на них в зависимости от
текущей ситуации. Масштабируемость системы, выражаемая
в виде способности системы подстраиваться к количественно
изменяющемуся и повышающемуся уровню потребностей. Ширина спектра предоставляемых системой возможностей по причине наличия, по сути, только лишь граней возможного-невозможного, внутри которых допустимы разнообразные вариации.
Гипотетический пример реализации паттерна. Представим, что у нас имеются в наличии довольно большие финансовые и социальные ресурсы, присутствует непреодолимая потребность их реализовывать, также имеется неограниченный
запас альтруизма, выражаемый в приверженности к спонсорству, и маниакальная склонность в обеспечении бесперебойного
функционировании рынка в плане соблюдения постоянного соотношения спроса с предложением. У нас есть некоторая заготовка, которая служит для нас средством реализации наших
потребностей. Т. е. имеется некоторая исследовательская служба,
которая осуществляет постоянный мониторинг рынка и ищет
новые ниши спроса для реализации предложения. Также у нас
имеется некоторый абстрактный шаблон того, что мы можем
предложить, и некоторый абстрактный шаблон того, как именно
мы это реализуем. При нахождении некоторого спроса (запроса)
в дело вступают службы реализации. Одна из многих заготовок
нашего производства быстро перепрофилируется под новый запрос, а заготовка продукции поступает в производство на этих
изменившихся условиях алгоритма производства. Как итог –
быстро полученный новый продукт, строго соответствующий
поступившему запросу с рынка. Суть здесь в наличии двух абстрактных заготовок и двух конкретных их реализаций.
Осмысление структуры паттерна. Центральный узел аб-
страктной фабрики, абстрактный класс, связан с конкретными
реализациями, конкретными фабриками, по типу агрегации,
т. е. он вполне способен существовать автономно и изначально
147
при запуске функционирующей системы именно так и происходит. Конкретные фабрики и продукты в зачаточном своем состоянии связаны с центральным узлом по типу композиции, т. е.
без него они бы не смогли существовать. Затем эти же отношения могут трансформироваться в отношения делегирования,
т. е. абстрактная фабрика делегирует некоторые ответственности и полномочия конкретной фабрике, затем же конкретная
фабрика функционирует достаточно автономно: контроль реализации конкретной фабрики для центрального узла заканчива-
ется на этапе создания, и далее ответственность не распространяется – все же это не контролер, а создатель. Т. е. конкретные
фабрики не являют собой подлинно внутренние компоненты
абстрактной фабрики, как происходит при классическом деле-
гировании, они есть ее более или менее автономные порождения.
Сильное зацепление отсутствует, а также, само собой разумеется, каждая конкретная фабрика должна быть сильно связана во
внутреннем смысле. Тип связи между отдельно взятыми конкрет-
ными фабриками зависит от текущей ситуации в рамках системы и определяется контекстом. Функционал каждой конкретной
фабрики по умолчанию инкапсулирован, и для взаимодействия
с иными принадлежащими системе ПК каждая конкретная фаб-
рика использует сугубо интерфейс.
Значимость паттерна в контексте разработки систем
сильного ИИ. Значимость «Абстрактной фабрики» для нужд
разработки систем сильного ИИ сложно переоценить. Достаточно вспомнить, что мы изначально упоминали о том, что этот
паттерн может (с некоторыми замечаниями, дополнениями и изменениями) составить определенный базис для интеллектуальной системы с претензией на сильный ИИ. Вообще же сама идея
наличия этой самой «заготовки на все случаи жизни» является
фундаментальной в широком контексте и не ограничена сферой
разработки ПК. В качестве наиболее яркого примера служит человеческий мозг, который в любом случае имеет некоторую нейробиологическую основу (абстрактная фабрика), которая гене-
рирует основу уже функциональную (абстрактный продукт)
в виде высшей нервной деятельности, которая, в свою очередь,
148
трансформируется в сложные психические процессы (конкрет-
ные фабрики), продуцирующие речь, поведение, все формы активности и так далее (конкретный продукт). Будет ли этот паттерн
столь же эффективен в контексте необходимости сформировать
не просто нейронную сеть как частный случай системы слабого
ИИ, а человекоразмерный объект – систему сильного ИИ – вопрос, само собой, открытый. Однако у нас есть только то, что
эффективно сработало на нас самих. Поэтому нам и необходимо
именно это апробировать на чем-то новом. В данном случае – на
системах, которые мы стараемся обеспечить сознанием. В любом
случае мы считаем, что структуру и идею паттерна «Абстрактная фабрика» необходимо использовать при подобного рода разработках, разумеется, в составе целостной системы.
11.2. Порождающий паттерн «Фабричный метод»
Идентификатор. Фабричный метод (Factory method).
Классические элементы. Продукт, конкретный продукт, со-
здатель, конкретный создатель.
Назначение. Создание центральным программным компонентом (центральным узлом) некой более или менее абстрактной основы для конкретных ПК с дальнейшей реализацией их
деталей при помощи подкомпонентов самого центрального узла.
Как указывают авторы Design patterns, «Фабричный метод»
«определяет интерфейс для создания объекта, но оставляет подклассам решение о том, экземпляры какого класса должны создаваться. Фабричный метод позволяет классу делегировать создание экземпляров подклассам» [114, с. 111].
Проблема. Необходимость наличия в системе конкретных
типов реагирования на различные ситуации, возникающие в процессе функционирования системы.
Концептуальное решение. Создание абстрактного класса со
способностью порождать заготовки других классов, конкретная
классовая принадлежность которых будет определяться непосредственно на местах их реализации. Переадресация ответственности за подбор необходимого класса для заготовки делегиру-
149
ется центральным узлом своим подкомпонентам и ими реа лизуется.
Предполагаемые результаты и преимущества. Способность системы быстро и эффективно реагировать на часто возникающие в процессе ее функционирования ситуации, отличающиеся широким спектром разнообразия. Высокая экономичность
и эффективность.
Гипотетический пример реализации паттерна. Представим себе компьютерную игру в жанре Action/RPG от третьего
лица (по типу Diablo). Игрокам предлагается выбрать игрового
персонажа из некоторого числа реализованных вариантов с определенной функциональностью, прописанными способностями,
своими преимуществами и недостатками. В различных ситуациях предлагаемые персонажи ведут себя по-разному, и каждый
из них лучше подходит к одной ситуации и хуже, соответственно,
к другой. Задача игрока в том, чтобы максимально эффективно
использовать сильные стороны выбранного персонажа и в то же
время наилучшим образом купировать его слабые стороны. Разумеется, менять персонажа во время выполнения (в runtime) не
представляется возможным. Так вот паттерн «Фабричный метод»
предоставляет некоторую заготовку подобного персонажа с этой
самой возможностью трансформировать его классовую принадлежность в runtime, что, разумеется, приносит неоспоримые
преимущества игроку. Еще один пример. Ситуация боевого
столкновения войск. Есть, к примеру, три возможные дистанции
боя: ближняя, средняя, дальняя. Допустим, что одно войско
лучше себя чувствует на ближней дистанции, а другое – противостоящее – на дальней. Соответственно, несложно предсказать,
что именно будет происходить при столкновении: те, кто лучше
себя чувствуют на дальней дистанции, будут, отступая, наносить урон, а те, кто более хорош в ближнем бою, будут стараться
навязать противнику именно его. Паттерн «Фабричный метод»
предоставляет возможность быть одновременно отличным войском на всех дистанциях в зависимости от имеющейся на поле
боя актуальной ситуации: войско просто смогло бы становиться
то одного типа войском, то другого. Или, краткий пример, как
150
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]