Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Сильный искусственный интеллект и объектно-ориентированное программирование синтез парадигм
.pdf
если бы боксер в бою начинал одинаково хорошо работать на
всех ударных дистанциях в зависимости от актуальных в бою.
Осмысление структуры паттерна. Центральный компонент (создатель) связан со своими заготовками (продуктом) по
типу агрегации: он без них изначально существует. Они же связаны с ним по типу композиции: без него они бы, разумеется, не
существовали. В то же время со своими подкомпонентами (конкретными создателями) центральный компонент связан уже наследственными связями: т. е. они обладают всеми его характеристиками (полями и методами) вместе с (возможно) некоторыми
дополнительно определенными. Связь же конкретного продукта
с конкретным создателем осуществляется по типу композиции.
Значимость паттерна в контексте разработки систем
сильного ИИ. Значимость «Фабричного метода» для сферы раз-
работки систем сильного ИИ также сложно переоценить. Система,
содержащая некоторое множество однообразных, эффективных
и относительно экономичных в производстве и использовании
«юнитов», способных эффективно подстраиваться под определенное множество возникающих в контексте ситуаций – весьма
эффективный паттерн. В рамках макромира наличествует множество эффективных иллюстраций его реализации. К примеру,
рефлекс. Здесь имеется множество так нами обозначаемых «юнитов», которые, каждый на своем уровне абстракции и реализации,
обеспечивают высоконадежное и бесперебойное функционирование всей системы в целом. Таким же образом простая заготовка инстинкта в его различных локальных (на местах) реализациях способна обеспечить эффективное выживание целых видов.
И мы считаем, что точно таким же образом этот положительный
опыт необходимо реализовывать также и в контексте разработки
систем сильного ИИ, закладывая саму идею в виде ее абстрактного определения, идею необходимости формирования некоторого множества эффективных заготовок (абстрактных продуктов), а точнее исходного наличия их производителя (создателя)
и его подсистем (конкретных создателей), которые будут отвечать за формирование наличествующих и эффективно реагирующих на различные ситуации «юнитов» (конкретных продуктов).
151
11.3. Порождающий паттерн «Строитель»
Идентификатор. Строитель (Builder).
Классические элементы. Строитель, конкретный строи-
тель, распорядитель, продукт.
Назначение. Создание конечных экземпляров по некоторому
шаблону, допускающему вариации и отхождения от оригинала
в случае с большим количеством своих компонентов, при помощи определенного алгоритма, реализующегося дискретно и целенаправленно пошагово (с очень четкой гранью между этапами).
Как указывают авторы Design patterns, «Строитель» «отделяет
конструирование сложного объекта от его представления, так
что в результате одного и того же процесса конструирования
могут получаться разные представления» [114, с. 103].
Проблема. Необходимость реализации различных конечных
продуктов за счет единого производственного процесса с максимально возможной экономичностью в плане использования этого производства.
Концептуальное решение. В данном конкретном случае концептуальных решений наличествует множество, но более или
менее каноничны два из них. Первое – создание строителя без
распорядителя, непосредственно под контролем клиента или
пользователя. В таком случае этапы единого процесса создания
конечного продукта (в данном случае – объекта) и последовательность этих этапов определяются самим пользователем,
а завершение функционирования строителя происходит в тот
момент, когда, по мнению пользователя, конечный продукт находится в завершенном состоянии. Второй же вариант более сложен вначале, но в дальнейшем является менее затратным и, что
характерно, предоставляет возможность быть повторно используемым. Он заключается в изначальном определении всех конкретных деталей конечного продукта и затем передаче запроса
на выполнение распорядителю. Затем уже распорядитель, на ос-
нове имеющегося у него заказа, использует строителя в соответствии со своим заданием.
Предполагаемые результаты и преимущества. Способность
системы экономить большое количество ресурсов на различных
152
вариациях процесса производства за счет его полного единообразия вместе с сохранением способности системы производить широкий спектр представляемой продукции. Как следствие: высокая экономичность и эффективность.
Гипотетический пример реализации паттерна. В данном
конкретном случае хорошо подходит крайне простой пример
с мясорубкой или соковыжималкой. Т. е. мы имеем дело с некоторым алгоритмом (в том самом смысле слова) действий, которые выполняются вне зависимости от контекста и приводят
к самым различным возможным результатам, обусловленным как
раз актуальным контекстом. Естественно, тут имеются и ограничения – алгоритм просто выполняет то, что ему предписано,
и вся ответственность ложится на распорядителя. Ситуация также отлично демонстрируется метафорой о «глупых рабочих»,
функционирующих по принципу «могу копать – могу не копать».
Осмысление структуры паттерна. В рамках структуры
данного паттерна весь процесс связан по типу композиции с центральным программным компонентом – распорядителем. И это
несмотря на то, что, как было сказано выше, порой данный паттерн реализуется без распорядителя вовсе. Просто в таком случае
место распорядителя занимает сам пользователь. Здесь актуальна метафора о том, что «все, что необходимо для того, чтобы
сделать танк – это заказ». И в данном случае имеет место конкретика, несколько отличная от предыдущих паттернов: конкретный строитель – это не сущностно строитель, а более
того – сущностно и в определенный момент реализации алгоритма строительства. Алгоритм сам по себе, на чем уже неоднократно акцентировалось внимание, выдаст одинаковый результат
при одинаковых входных данных – и это крайне ценная особенность алгоритмов. В рамках паттерна «Строитель» этот факт
был реверсирован, и его суть была применена таким образом,
чтобы один и тот же алгоритм построения конечных продуктов
выдавал как можно большее разнообразие результатов. Конкрет-
ный строитель связан со строителем по типу агрегации в обе
стороны: в некотором роде они оба друг без друга могут существовать. Т. е. в данном случае каждый этап реализации
153
алгоритма способен существовать и отдельно от целостного алгоритма. Также паттерн выделяется тем фактом, что он, как уже
говорилось, подразумевает инкапсуляцию вырванного из контекста алгоритма.
Значимость паттерна в контексте разработки систем
сильного ИИ. Несмотря на некоторую нестандартность паттер-
на, он представляет собой очень даже немалую ценность для
разработки систем сильного ИИ. Таким же образом функционирует, к примеру, и сам процесс развития живых существ на длительном отрезке времени. Т. е. в рамках развития существ происходят определенные эволюционные скачки, результат которых
целиком и полностью зависит от контекста – в точности как
у алгоритма. Подобного же рода механизмы необходимы и для
процесса творческого развития личности, к примеру, да и в целом для осуществления жизнедеятельности любого живого существа. Резюмируя паттерн, следует заметить, что в контексте
разработки систем сильного ИИ по умолчанию необходим алгоритм именно такого рода. Разумеется, он не будет и не должен
быть единственным, но то, что именно автономно функционирующий, вырванный из контекста «рабочий» алгоритм будет
являть собой одну из центральных составляющих системы
силь ного ИИ, очень даже вероятно.
11.4. Порождающий паттерн «Прототип»
Идентификатор. Прототип (Prototype).
Классические элементы. Прототип, конкретный прототип.
Назначение. Формирование различных ПК по определенно-
му наличествующему базовому шаблону ПК. Как указывают авторы Design patterns, «Прототип» «задает виды создаваемых
объектов с помощью экземпляра-прототипа и создает новые
объекты путем копирования этого прототипа» [114, с. 121].
Проблема. Необходимость многократного повторного использования наличествующего шаблона для экономии ресурсов на
реализацию в каждом конкретном случае нового ПК.
Концептуальное решение. Формирование некоторого шаблона, который одновременно является и заготовкой определен-
154
ного ПК, и его непосредственной конкретной реализацией. Ключевой особенностью шаблона, формируемого в контексте данного
паттерна, является его способность к репликации. Т. е., по сути,
в контексте системы формируется некоторая группа базовых
ПК, каждый из которых обладает определенным прототипом.
Сам по себе прототип, не как паттерн, а как контекстуальный
феномен и составляющий элемент паттерна, представляет собой, в сущности, абстракцию класса, т. е. совокупность всех его
значимых характеристик, свойств и особенностей, и, самое главное, заключает в себе способность к репликации. После то го,
как все базовые ПК (прототипы) реализованы и определены,
новые ПК (конкретные прототипы) формируются путем копирования базовых, определенных на этапе формирования системы компонентов. Вообще очевидно, что создание нового объекта путем копирования прототипа уже существующего объекта
вполне себе напоминает типичное наследование классов – один
из ключевых аспектов ООП в целом. Посему может стать не
вполне понятно, для чего вообще классический механизм ООП
выделять в отдельный паттерн. Однако есть одно важное отличие обычного наследования классов от создания объектов при
помощи прототипного программирования. А именно: при наследовании классов на основе уже существующего класса создается новый класс, а на основе клонирования прототипа создается новый объект. Таким образом, если при наследовании классов
новый объект-экземпляр будет создан только после создания
класса, дочернего по отношению к классу родительскому, то прототипное программирование позволяет сократить эту цепочку
на одно звено, тем самым ускорив процесс на треть.
Предполагаемые результаты и преимущества. Высокая
производительность и скорость функционирования системы
в контексте создания новых ПК.
Гипотетический пример реализации паттерна. В случае
с паттерном «Прототип» обычно приводимым классическим
примером является деление клеток – митоз. Т. е. разделение одной клетки на две путем «разрыва» клеткой самой себя. Разумеется, что у делимой клетки должен изначально наличествовать
155
потенциал к подобному действию. В рамках программной реализации данный потенциал резюмирован в методе, который, как
правило, называется clone (клонирование). Пример с клонированием также является одним из наиболее часто упоминаемых
при иллюстрировании специфики данного паттерна. В некотором роде клонирование является не полностью корректным примером по той причине, что та же овечка Долли не сама себя клонировала, а вот прототип именно сам себя и клонирует при
помощи вызова метода clone. В контексте упоминания уже известных примеров мы бы хотели дополнить этот список, возможно, не столь очевидным, но тем не менее весьма интересным
феноменом. А именно – фрактал. Нам представляется несколько
похожей на структуру фрактала система, которая функционирует
на основе паттерна «Прототип». Вспомним, что фрактал представляет собой самоподобный, вне зависимости от ранжирования, объект. Т. е. все его составляющие, все его, как целого,
части как раз представляют собой его самого. Разница между
целостной структурой фрактала и частей, его составляющих,
представляется сопоставимой с разницей между ключевыми
элементами паттерна «Прототип»: прототипом и конкретным
прототипом.
Осмысление структуры паттерна. Прототип, как ключе-
вой элемент паттерна, связан со своими порождениями – конкретными прототипами – по типу агрегации, т. е. он способен существовать без них. Они же связаны с ним по типу композиции,
т. е. без него они бы не существовали. Также зачастую в классических примерах реализации данного паттерна дополнительно
выделяется связь прототипа с еще одним элементом структуры
паттерна – клиентом – по типу композиции, так как прототип
не может существовать без клиента (по принципу «не бывает
танка без заказа»). Мы упомянутую связь, как и элемент клиент
или пользователь в структуре данного паттерна, дополнительно
обозначать не видим целесообразности, так как это дополнение
напоминает дискуссионную метафору «пахнет ли роза, когда ее
никто не нюхает».
156
Значимость паттерна в контексте разработки систем
сильного ИИ. В контексте разработки систем ИИ при посред-
стве паттернов ООП мы, как видно из наших последовательных
постулатов, апеллируем к выявлению наиболее общих и естественных закономерностей, которые затем, в перспективе, можно
будет реализовать аппаратно-программным образом, т. е. физически на некоем агрегате, который нами представляется как реальная физическая основа для возникновения технотропного
сознания таким же образом, каким возникло антропное человеческое сознание на биологической основе физического тела. Соответственно, в контексте данного паттерна мы можем постулировать его абсолютную фундаментальность для такой базовой
функции, как репликация. Репликация ДНК, деление клеток,
фрактальность (как одно из базовых свойств мироздания) – все эти
феномены свидетельствуют о том, что ключевые абстрактные
аспекты паттерна «Прототип» должны быть учтены при формировании системы сильного ИИ.
11.5. Порождающий паттерн «Одиночка»
Идентификатор. Одиночка (Singleton).
Классические элементы. Одиночка.
Назначение. Производство программных компонентов. Точ-
нее, в данном случае, программного компонента. Как указывают
авторы Design patterns, «Одиночка» «гарантирует, что у класса
существует только один экземпляр, и предоставляет к нему глобальную точку доступа» [114, с. 131]. Вообще говоря, сразу же
возникает некоторый вопрос: зачем создавать класс, у которого
в процессе его жизнедеятельности будет только один объектэкземпляр, а не использовать вместо этого класс со статическими
методами? Казалось бы, что отсутствие необходимости создавать экземпляры является весьма серьезным подспорьем в контексте уменьшения количества действий программной системы.
Примерно как отсутствие необходимости создавать подклассы
конкретного класса, как мы уже убедились на примере паттерна
«Прототип». Однако в случае с паттерном «Одиночка» есть
157
один нюанс. А именно – гибкость. Класс со статическими методами (статический класс) предоставляет куда меньше возможностей, чем объект-экземпляр, который позволяет внести больше
типов полей (данных) в ПК. Также необходимость наличия «Одиночки» обусловлена тем, что не во всех языках программирования удобно использовать статические классы. По крайней мере,
этот факт был весьма актуален на момент разработки данного
паттерна.
Проблема. По сути, потребность в «Одиночке» может возникать в тех случаях, когда в рамках конкретной программной
системы необходимо создать доступ к очень гибкой и многофункциональной глобальной точке (переменной).
Концептуальное решение. Формируется ПК, в данном случае класс, который является, по сути, стандартным классом, но
отличается от обычного тем, что позволяет создать только один
свой объект-экземпляр. Также этот ПК при обращении к нему
в первый раз создает свой экземпляр, а при всех последующих
к нему обращениях из любой точки системы он просто предлагает этот самый экземпляр, который теперь является его «представителем». Этот объект не является посредником между классом и пользователем, он просто аккумулирует в себе всю суть
класса и, будучи единожды созданным, просто далее функционирует.
Предполагаемые результаты и преимущества. Стоит заметить, что данный ПП является одним из наиболее знаменитых в нынешнее время. Предполагается, что реализация паттерна «Одиночка» позволит сформировать в рамках программной
системы некую глобальную точку доступа к общему широкому
функционалу. Подразумевается, что данная точка доступа, реализуемая «на месте» объектом-экземпляром, способна к высокому уровню эластичности, т. е. она не сопротивляется трансформации своего функционала. На самом деле эта особенность
реализации данного паттерна являет собой «палку о двух концах», т. е. она представляется огромным плюсом в тех случаях, когда необходимо быстро изменить общий функционал, и очень неприятным минусом в тех случаях, когда этот самый общий
158
функционал трансформируется бесконтрольно и неожиданно.
Вообще любой случай с любой глобальной переменной напоминает две полярности и некоторый между ними баланс: в первом
полярном случае все вещи в доме были бы прибиты к полу гвоздями, а во втором – каждую ночь в доме проводилась бы хаотичная перестановка. Собственно говоря, паттерн «Одиночка»
как раз и представляет собой пример попытки найти баланс
между вышеозначенными полярностями.
Гипотетический пример реализации паттерна. Крайне
показательно иллюстрирует суть «Одиночки» так называемая
служба «одно окно». Также классические примеры реализации
паттерна в контексте макромира касаются различных краеугольных камней в рамках некой системы: президент страны,
начальник на работе и т. д. Иные примеры касаются вещей, используемых в быту, и построены по принципу того, что «мы не
покупаем новую кружку каждый раз, когда хотим попить чаю».
Нам же довольно подходящим видится следующий пример: человеческое сознание. Оно формируется один раз, а затем только
лишь функционирует и трансформируется. У человека как пользователя есть к нему глобальный доступ и оно – сознание –
находится в режиме непрерывной динамики и трансформации.
К тому же у него отсутствуют дубликаты (другие экземпляры
класса). В этом смысле сознание и есть человеческий внутренний singleton (одиночка).
Осмысление структуры паттерна. Вообще говоря, в классическом понимании этого паттерна в Design patterns, у него отсутствуют связи с чем-либо и классический элемент всего один.
Однако нам, в контексте максимально возможного абстрагирования сути паттерна, представляется иначе. Если внимательно
исследовать структуру паттерна, то в наличии оказывается ПК
(класс), который содержит в себе потенциал однократного воспроизведения второго ПК (объекта-экземпляра) и изначально
аккумулирует в себе всю его суть. Соответственно, непротиворечиво выглядит постулат о том, что объект-экземпляр связан
с классом по типу композиции – объект не способен существовать без класса, а класс связан с экземпляром по типу агрегации,
159
т. е. класс может сколь угодно долго существовать без объекта.
После же того, как объект создан при помощи первого вызова
метода класса, их отношения начинают напоминать обоюдную
композицию – один не способен существовать без другого.
Значимость паттерна в контексте разработки систем
сильного ИИ. В контексте разработки систем сильного ИИ ПК,
который аккумулирует в себе потенциал однократного порождения некой мощной значимой сущности с широкомасштабным,
динамически трансформируемым интерфейсом, является крайне значимой составляющей. Вообще образ действия, включающий
однократное порождение чего-либо значимого с последующим
фактическим «уходом в тень» создателя, является практически
библейским по уровню архитипичности. Использование подобного механизма нам представляется также весьма диалектическим и напоминает один из законов диалектики – перехода количества в качество. Т. е. некоторая сущность функционирует
согласно некоторой специфике определенное время – до конкретного события. А затем, после активации триггера, специфика
функционирования данной сущности претерпевает необратимые
трансформации и некоторым образом переходит к реализации
совершенно иного функционала. Собственно говоря, примерно
в подобном ключе нам и представляется возникновение феномена технотропного сознания – сущность резко и необратимо,
скачкообразно его приобретает и после этого уже становится
сущностью вовсе иного типа. Если же абстрагировать данный
паттерн еще сильнее, то таким же образом, каким функционирует
паттерн «Одиночка», в максимально широком смысле, нам видится весь процесс создания системы сильного ИИ. Т. е. изначально формируется некоторая основа, обладающая определенным потенциалом. Все происходит примерно по канонам
абстрактного класса. Затем эта основа интегрируется в среду реализации своего потенциала, которая может быть максимально
разнообразной, – «первичный бульон», как изначально на планете Земля. Далее начинает осуществляться взаимодействие сущности и среды. После определенных нескольких (возможно, квадриллионов в n-й степени) симуляций и возникающих в их
160
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]