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

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

терн «Посетитель» являет собой отражение некоторых фунда­ментальных биологических процессов. Соответственно, мы счи­таем целесообразным применять его абстракции в контексте разработки систем сильного ИИ именно в этом ключе. Т. е. не­обходимо реализовать в рамках интеллектуальной системы ме­ханизм реализации самой возможности одних компонентов системы трансформировать другие компоненты системы специ­фическим образом и не обязательно, а ситуативно, в зависимости от контекста, а также таким образом, чтобы не осуществлялось изменение самой сути всех компонентов, а только лишь транс­формировался «фенотип» непосредственно изменяемых. Соот­ветственно, необходимо некоторым образом оформить способ-

Паттерн «Цепочка обязанностей» в общем смысле предпола­гает формирование гиперссылочного типа мышления в рамках программной системы, тем самым определяя одну из возможно­стей возникновения подобного феномена у сильного ИИ среди прочих вариантов «образа мысли».

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

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

В паттерне «Интерпретатор» в процессе исследования были выявлены фундаментальные аспекты (если провести аналогию с человеком) обработки неких ощущений и преобразования их в восприятие в общем смысле слова. В частности, в рамках пат­терна был исследован феномен, который определяется как аб-

Таким образом, основываясь на вышесказанном, мы предпо­лагаем необходимость реализации в контексте разработки си­стем сильного ИИ абстрагированной сути поведенческих пат­тернов ООП. Дополним, что проведение данного мероприятия должно осуществляться с учетом необходимости корректных адаптаций самих паттернов к контексту парадигмы сильного ИИ, которые, собственно, нами и производятся в ходе текущего исследования.

разработки программного обеспечения (посредством, в том чис­ле, и структурных паттернов) и в макромире. Если представить некую систему, которая изначально была более или менее одно­образной, но затем начала претерпевать некоторые трансформа­ции, в ходе которых из различных компонентов образуются более крупные структуры, то сразу же придет аналогия с гравитаци­ей, т. е. с ситуацией, в рамках которой более крупный объект притягивает к себе более мелкие для дальнейшего осуществле­ния процесса глобального «бодибилдинга». Или, к примеру, когда, согласно некоторым психоаналитическим традициям, из изна­чально незначительно дифференцированной человеческой психи­ки начинают формироваться «Эго», «Супер-Эго», «Оно» – про­цесс «бодибилдинга» уже интерпсихического. Примеры можно продолжать, но суть ясна – структурные паттерны в рамках раз­работки компьютерных программ упорядочивают и регламен­тируют те же самые процессы в абстрактном их виде. И если, к примеру, поведенческие паттерны выполняют то же самое с функциональной точки зрения, то структурные паттерны, как видно непосредственно из их определения, делают это со струк­турной точки зрения.

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

Здесь можно было бы сказать: не проще ли сразу адаптиро­вать целевой к адаптируемому и не вводить третий компонент? Само собой разумеется, что не проще. Допустим, мы именно это и сделали, т. е. определили в программном компоненте, который определяется как целевой, методы, которые осуществляют пре­образование запросов целевого в запросы, которые, используя интерфейс адаптируемого, способны объяснить ему «на его языке», чего именно от него хотят, и добиться выполнения этого запроса. Т. е. мы, зная, на что идем, нарушаем фундаменталь­ный принцип сильной связности и принцип единственной от­ветственности из числа принципов SOLID для того, чтобы за­просы нашего ПК преобразовывались в запросы (конкретные и точные), которые формируются с учетом пользовательского интерфейса другого ПК, причем именно одного этого, а не како­го-либо иного. Помимо крайне нежелательного нарушения важ­ных принципов это плохо еще кое-чем. Так как, возможно, через некоторое время нам снова понадобится адаптировать наш целе­вой ПК, но уже к другому адаптируемому. И мы каждый раз вынуждены будем добавлять новую функциональность, которая не является свойственной для компонента, тем самым «закапы­вая» его основной функционал все глубже и глубже. Разумеется, так поступать нельзя, так как система, основанная на таких ком­понентах, станет не поддерживаемой. Причем даже это только в том случае, если у нас есть возможность изменить целевой компонент, что далеко не всегда возможно. Невозможно это, на­пример, когда у нас есть два программных компонента и оба яв­ляются привнесенными извне.