Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Сильный искусственный интеллект и объектно-ориентированное программирование синтез парадигм
.pdf
лее, определяющие специфику формирования ПК. Так как при
построении интеллектуальных систем доминирующей является
парадигма ООП, то мы будем ориентироваться именно на ее
особенности.
Считается, что парадигма ООП зародилась из потребности
повышения удобства разработки, а соответственно, и удобочитаемости и выражалась в «уравнивании в правах» данных,
т. е. информации, и методов для работы с этими данными,
а именно алгоритмов. Идея возможности «срастить» в единую
структуру информацию и способы ее использования значатся за
авторством Кристена Нюгорта и Оле Джохана Дала в период их
работы над языком программирования Simula-1 и были впервые
ими реализованы в Simula-67 [111, 112]. Созданная в результате
объединения данных и алгоритмов структура и получила название «объект». Затем уже концепция получила развитие (по отличающемуся в каждом случае сценарию) в языке Smalltalk у Алана Кея (изначально он применял термин «модуль» как аналог
объекта) и в C++ у Бьёрна Страуструпа. Автором же самого понятия «объектно-ориентированное программирование» считается Алан Кей [113]. Интересный факт заключается в том, что
несколько позднее по схожей схеме – уравнивание в правах различных типов данных, – но уже не в рамках формирования некой
общей структуры, а по отношению сугубо к алгоритмам была
оформлена иная методология – функционального программирования. В ООП зачастую принято отождествлять объект в рамках ООП с самой методологией, так как он, являясь смысловым
средоточием и инстанцированием всех ее фундаментальных
особенностей, представляет «живой пример» функционирования
всей методологии ООП в целом. Ключевым же понятием ООП
является класс, т. е. наиболее абстрактный способ определения
состояния программной сущности (данные), ее поведения (алгоритмы), а также программного интерфейса для взаимодействия
с этой сущностью со стороны других программных сущностей.
Фундаментальными свойствами класса как системы отношений между его компонентами являются инкапсуляция, полиморфизм, наследование, абстракция и интерфейс.
111
Инкапсуляция – это способность связать в рамках класса
информацию и алгоритмы (поля и методы) и завуалировать
специфику их взаимодействия, т. е. скрыть все внутренние процессы, оставив доступ лишь к интерфейсу. Сама способность
инкапсуляции с точки зрения целесообразности выглядит непротиворечиво и, при экстраполировании ее сути на объекты
макромира, имеет множество примеров (человеческий череп
и мозг, выделяющиеся надбровные дуги у неандертальцев, вообще все внутренние органы и т. д.). Т. е. скрывать наименее прочное и наиболее значимое под наиболее прочным и наимением
значимым – вот суть инкапсуляции, а также специфика взаимоотношений между инкапсуляцией и интерфейсом.
В свою очередь интерфейс – это совокупность «входных точек» отдельного класса, т. е. всех его публичных данных
и публичных методов для работы с этими данными. Все, что доступно в классе для использования другими классами, входит
в интерфейс. Интерфейс также, несомненно, выглядит естественным и напоминает некоторую систему отношений между сущностями, в которой зафиксированы все возможные варианты
взаимодействия. Довольно ярким примером в реальном мире
может служить культура языка с конечным количеством слов
и вариантов построения словарных последовательностей, т. е. любого языка в мире.
Полиморфизм – это способность экземпляров одного и того
же класса быть успешно реализованным в принципиально разных контекстах, но с сохранением единого интерфейса для всех
возможных контекстов. Это также способность методов с одинаковым интерфейсом успешно обрабатывать различающиеся типы
данных и, в свою очередь, способность «дочерних» классов быть
использованными в контекстах, изначально предназначавшихся
для классов «предков». Очевидно, что полиморфизм также кажется естественной и целесообразной способностью, так как,
к примеру, сам человеческий организм также им обладает и, к слову, употребление языковых конструкций иносказательно – пример полиморфизма.
112
Наследование – это способность к «продолжению рода» с сохранением в «потомках» характерных особенностей «предков»
в той или иной степени. Здесь, помимо ярко выраженной естественности данной способности ПК в ООП, стоит также отдельно сказать о столь же яркой выраженности практической значимости
наследования. А именно: наследование позволяет многократно
использовать части компьютерной программы какое угодно количество раз, не переписывая их снова и снова.
Абстракция же – это совокупность наиболее значимых характеристик программной сущности. Можно сказать, что специфичность «абстрактной палитры» и составляет фундаментальную
основу для идентичности любой сущности в ООП. И в данном
случае также прослеживается прямая связь между системным
свойством в методологии ООП и «естественным положением
вещей». Здесь напрашивается аналогия с понятием эйдоса у Платона. Т. е., к примеру, один человек может очень сильно отличаться от другого, но и тот, и другой признают друг друга людьми. Также человек может лишиться ноги или руки, но от этого
он не перестанет быть человеком, так как отсутствует качественное преобразование сущности. И именно эта «качественность»,
которая делает человека человеком, и составляет «абстракцию
человечности» – меру количественных преобразований, необходимых и достаточных для того, чтобы можно было точно сказать, где еще есть человек, а где его уже нет. Реализована ли
идея (класс) человека на конкретной сущности или же сущность
стала субстратом для реализации некой иной идеи – для ответа
на данный вопрос и предназначена абстракция. Также, особенно
в случае с множественным наследованием, выглядит непротиворечивой параллель с архетипами Юнга, которые являются более мягкой версией паттерна «Прототип» (см. гл. 11) – наследуемого синтеза абстракций класса [114].
Из понятия класса иерархически «производится» понятие
объекта, который представляет собой конкретный экземпляр
конкретного класса. Объект сочетает в себе три ключевые составляющие: состояние – совокупность всех свойств вместе со
значениями этих свойств; поведение – совокупность всех мето-
113
дов (алгоритмов) объекта; и идентичность, т. е. некоторая аутентичность, уникальность и так далее, – отличия одного объекта
класса от другого объекта класса.
Из вышесказанного явно прослеживается существенная непринужденность формирования аналогий между ключевыми
аспектами методологии ООП и макромиром с человеком в его
рамках, так как действительно у каждого человека присутствуют специфические особенности, заданные «классом» (классом
в контексте ООП): две руки, две ноги, голова, системы кровообращения, дыхания, пищеварения и т. д. Также у каждого человека в той или иной степени наличествуют характерные особенности, полученные им от родителей, ими от их родителей, от
национальности в целом и прочее. Человек, наконец, обладает
и состоянием, и поведением. И эти пересечения не являются
случайными, так как при формировании парадигмы ООП в нее
(как, собственно, и в любую иную методологию программирования) закладывалась идея интуитивно понятного и удобного
для разработчиков функционала, сформированного при помощи
этой методологии. По крайней мере настолько, насколько это
вообще возможно в имеющихся рамках.
Далее можно резюмировать, что основы ООП выглядят естественными и непротиворечивыми с точки зрения целесообразности построения ПК. Однако на данный момент при помощи
ООП как доминирующей методологии ни в сфере формирования ИИ, ни вообще в области разработки программного обеспечения не было создано «экземпляров» сильного ИИ. И нами
предполагается, что причина может заключаться в следующем:
инкапсулированный человеческий мозг в черепе с передним интерфейсом вряд ли предполагался именно и только таковым, –
скорее всего, вариантов было (а может быть, и есть) на несколько
сотен порядков больше. Однако общий принцип целесообразности в рамках данного нам контекста макромира иным предполагаться не мог вовсе. Так же, как и «жизнеспособность» самой инкапсуляции. А затем уже, в рамках целесообразности и сугубо
естественным путем, путем самоорганизации, и был сформирован именно такой «порядок вещей»: интерфейс – спереди
114
и именно такой, а мозг – именно такой, внутри черепа и с определенными характеристиками.
Т. е. при формировании закономерностей для какой-либо системы необходимо делать их в общем смысле целесообразными
для этой системы (как вселенские константы), но столь же необходимо создавать условия для запуска естественного самоорганизующегося процесса, в рамках которого и будут определены
все возможные варианты развития системы и детали этого развития. С учетом научно-технических реалий мы в данный момент говорим о формировании самоорганизующегося паттерна,
порождающего некие подпаттерны при каждой ранее не встречавшейся задаче, связывающего затем их в единый опыт (некоторое воплощение синтеза паттернов, подобных «Абстрактной
фабрике» и «Шаблонному методу») (см. гл. 11, 12) из GoF-паттернов с некоторыми существенными расширениями, дополнениями и адаптациями, конечно. Т. е. буквально мы имеем в виду
следующее: не прописывать детально все поля и их значения,
как и методы для работы с этими полями, а изначально формировать лишь «абстракцию целесообразности» и определенный
набор возможностей – по сути «законы физики» локального киберпространства. Если говорить в более общем смысле, то перспективным, с точки зрения формирования систем сильного ИИ
при помощи методологии ООП, выглядит некое утрирование
пятого принципа SOLID – принципа инверсии зависимостей
из состояния «все должно зависеть только от абстракций» до
«должны наличествовать только абстракции», в числе которых
целесообразность и возможность самоорганизации [115].
Ранее мы пришли к выводу о том, что парадигма ООП с точки зрения своих общих аутентичных характеристик отвечает
требованиям целесообразности и некоторой естественности,
в соответствии с которой и должны, по нашему мнению, создаваться системы сильного ИИ. Однако отсутствие сформированного сильного ИИ как такового заставляет, в соответствии с озвученной нами выше гипотезой, полагать, что для реализации
этого все же чего-то не хватает или же, напротив, нечто существенно этому мешает.
115
Формирование паттернов, подобных тому, который был нами
предложен и абстрактно охарактеризован, зиждется в первую
очередь на «резюмировании принципов в методах», т. е. на реализации высокоуровневых абстракций за счет определения
«эссенции» их практикоориентированности и дальнейшего ее
применения на низкоуровневом «субстрате». Т. е., по сути, происходящее является редуцированием фундаментальных аспектов
теории к «злободневным» потребностям практики. Само со бой
разумеется, что исследование заявленной проблематики в таком
контексте в большей степени попадает под юрисдикцию, к примеру, теории алгоритмов вообще, чем какой-либо парадигмы
программирования. Тем не менее в рамках каждого отдельного
подхода к построению ПК более общие принципы (к примеру, те
же принципы теории алгоритмов) реализуются с опорой непосредственно на дисциплинарные, внутренние принципы конкретной парадигмы. Т. е. на практике все происходит вполне диалектически: единое содержание принимает различные формы.
В связи с этим считаем необходимым дать краткую характеристику принципов ООП.
Принципы вообще, как общенаучные понятия, мы будем определять как фундаментальные постулаты, регламентирующие
формирование самого контекста предметной области. В рамках
ООП принципы можно, по сути, разделить на две группы: структурные и организационные. Первые из них можно условно разделить на несколько подуровней по «степени фундаментальности». К примеру, обозначенные нами ранее в качестве ключевых
характеристик инкапсуляция, наследование, полиморфизм, абстракция и интерфейс в общем смысле также относятся к структурным принципам. Однако их специфика и значимость для
ООП несколько выше, чем у остальных, в том смысле, что без
них вообще не было бы данной парадигмы. Поэтому они обозначаются нами как базовые системные свойства – свойства системы
объектно-классовых отношений. А вот без остальных принципов вопрос о самом существовании парадигмы не ставится – она
бы просто стала иначе и с практической точки зрения гораздо
хуже функционировать. В рамках текущего исследования нам,
116
соответственно, важнее структурные принципы, но тем не менее для полноты картины мы также дадим краткую характеристику и принципам организационным, так как те и другие, разумеется, взаимосвязаны.
Здесь стоит отдельно упомянуть о том, что организационные принципы не являются уникальными для рассматриваемой
нами методологии, а представляют скорее универсальные постулаты, характерные для многих подходов к программированию. Еще следует сказать, что мы не будем в данном контексте
упоминать о внутренних организационных принципах некоторых отдельно взятых объектно-ориентированных языков программирования, к примеру о Zen of Python и прочих. Мы охарактеризуем только те из организационных принципов, которые
полноправно применяются в рамках ООП в целом. Касаемо же
структурных принципов, также стоит заметить, что мы будем
останавливаться только на тех из них, которые являются общеметодологическими, не затрагивая локальные принципы отдельных внутренних концепций, к примеру принципы REST, MVC
и иные.
Начать мы полагаем со структурных принципов. К наиболее
фундаментальным принципам ООП, по нашему мнению, следует отнести два:
принцип сильной связности / сильная связность (High Cohesion)
принцип слабого зацепления / слабое зацепление (Low Coupling)
Для начала необходимо уточнить, что же такое вообще связность и зацепление в программировании. Во-первых, следует
сказать, что в связи с некоторыми нюансами перевода связность
нельзя путать со связанностью, несмотря на их созвучность, так
как связанность является синонимом зацепления (это взаимозаменяемые понятия), а связность, соответственно, антонимом.
Связность представляет собой способ и степень взаимосвязи-взаимозависимости ПК во внутреннем смысле, т. е. одного
элемента ПК по отношению к другим элементам этого же ПК.
Выделяют следующие по возрастанию степени, типы связности:
случайная, логическая, временная, процедурная, связность взаимодействия, связность последовательности действий, функци-
117
ональная. Идеальная сильная связность ПК означает, что все его
элементы тесно объединены в контексте достижения некоторой
единой общей цели и сам ПК выполняет как можно меньше неспецифичных для него задач, а в идеале – всего одну «большую»
задачу. Слабая связность означает, соответственно, обратную
ситуацию.
Зацепление представляет собой способ и степень взаимосвязи-взаимозависимости ПК во внешнем смысле, т. е. одного компонента системы по отношению к другим компонентам системы.
Выделяют следующие по убыванию степени, типы зацепления:
зацепление содержимого, через общее, через внешнее, по управлению, по структурам данных, через данные, по сообщениям,
а также отсутствие зацепления. Идеальное слабое зацепление
означает такую ситуацию в рамках системы, в которой каждый
ПК обладает высоким уровнем самодостаточности и в малой
степени зависит от других компонентов. Также слабое зацепление означает возможность эффективного повторного использования ПК системы в других контекстах. Сильное зацепление,
соответственно, инвертирует этот смысл.
Здесь будет целесообразно заметить, что все остальные
принципы ООП в той или иной степени всего лишь дополняют
и уточняют смысл вышеизложенных принципов слабого зацепления и сильной связности. Грамотное сочетание слабого зацепления и сильной связности позволяет создавать удобные в использовании и повторном использовании, легко поддерживаемые
и читабельные программы. С точки зрения практического программирования значимость этих принципов сложно переоценить.
С философско-методологической же точки зрения идеальная
реализация синтеза этих принципов ведет к такой ситуации,
в которой наличествует некоторое количество абсолютно независимых самодостаточных и самоорганизованных ПК, каждый
из которых имеет возможность формировать сцепку с любым
другим программным компонентом в контексте текущей задачи, т. е. все без исключения компоненты конгруэнтны друг другу. Соответственно, в такой ситуации предоставляется возможность объединения любого количества любых компонентов для
118
решения любой конкретной задачи. Из этого следует, что смоделированная нами ситуация идеальной реализации фундаментальных принципов находится в полном соответствии с предложенной нами ранее концепцией абстрактного паттерна для
обработки данных со стороны системы сильного ИИ с той лишь
оговоркой, что конкретная специализация каждого ПК в случае
с предполагаемой нами концепцией не предусматривается, а вместо
этого определяется только общий потенциал – грани возможногоневозможного. С точки зрения целесообразности и естественности
означенных принципов следует отметить, что при обобщении
смысл смоделированной нами ситуации оказывается следующим:
наличествует энное количество «строительного материала»,
специфика которого позволяет создать любой возможный синтез формы и содержания, потенциально обладающий крайне
широким функциональным спектром. Отсюда сама собой следует
аналогия с атомом, квантом или вообще любым «строительным
материалом» бытия. Таким образом, фундаментальные принципы ООП – слабого зацепления и сильной связности – являются
как целесообразными, так и, конечно же, естественными.
На основе рассмотренных принципов иерархическим образом
формируются остальные, из которых нами будут охарактеризованы принципы группы SOLID. Данное понятие было введено
Майклом Фэзерсом и указывает на первые пять определенных
Робертом Мартином принципов ООП [116]. SOLID представляет
собой аббревиатуру, образованную от менее фундаментальных,
чем ранее указанные, но тем не менее также фундаментальных
принципов ООП: Single responsibility principle – принцип единственной ответственности, Open-closed principle – принцип открытости-закрытости, Liskov substitution principle – принцип подстановки Барбары Лисков, Interface segregation principle – принцип
разделения интерфейса и Dependency inversion principle – принцип
инверсии зависимостей. Кратко охарактеризуем каждый из них.
Принцип единственной ответственности. Суть данного
принципа заключается в следующем: ПК должен быть ответственным только за одну задачу. Как можно заметить уже из названия, данный принцип уточняет и конкретизирует сильную
119
связность, дополняя к уже сказанному о ней то, что ПК должен
иметь только одну причину для изменений. Реализация этого
принципа на практике служит для предотвращения ошибок,
связанных с возможным сложно прогнозируемым изменением
поведения ПК в каком-либо одном присущем ему аспекте из-за
изменений в некотором ином ему же присущем аспекте.
Принцип открытости-закрытости. Суть данного принципа заключается в следующем: ПК должны быть открыты для
расширения, но закрыты для изменения. Хоть это и не сразу очевидно, однако данный принцип тесно перекликается как со слабым зацеплением, так и с сильной связностью. На практике этот
принцип одновременно служит как для предотвращения ошибок, связанных с возможными внутренними изменениями ПК,
так и для предотвращения общих системных ошибок в результате, к примеру, каскадных изменений поведения цепочки зависимых классов из-за изменения в одном из них.
Принцип подстановки Барбары Лисков. Суть принципа
в следующем: в рамках программной системы любые объекты-экземпляры класса-предка могут быть заменены объектами-экземплярами класса-потомка без ухудшения функциональности; также дочерние классы должны только лишь дополнять,
но не переопределять функционал базового класса. Этот принцип так же, как и предыдущий, перекликается и с сильной связностью, и со слабым зацеплением. На практике, соответственно,
он служит для предотвращения ошибок в обоих упомянутых
контекстах, так как его нарушение, к примеру переопределение
какого-либо из методов базового класса, может привести к негативным изменениям в системе в целом.
Принцип разделения интерфейса. Его суть резюмируется
следующим образом: ПК не должны зависеть от методов, которые они не используют. Тут очевидно, что данный принцип
наследует смысл сильной связности, конкретизируя необходимость отсутствия всякой избыточности как в плане ответственности, так и в контексте рационального использования ресурсов.
Т. е. в случае, если в рамках компонента инкапсулированы методы, которые не являются необходимыми для осуществления
120
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]