Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Сильный искусственный интеллект и объектно-ориентированное программирование синтез парадигм
.pdf
им деятельности в соответствии с его ответственностью, то, во
избежание возможных ошибок при использовании данного компонента, «лишняя» функциональность должна быть связана
в новый ПК с уже новой специфической ответственностью. Отсюда очевидна практическая значимость данного принципа,
которая заключается как в повышении читабельности кода и упрощении повторного использования компонентов, так и в превентивном устранении возможных «багов». В целом же принцип
довольно недвусмысленно направляет процесс разработки в сторону смоделированной нами ранее идеальной реализации сильной связности / слабого зацепления.
Принцип инверсии зависимостей. Уже упоминавшийся
нами ранее принцип, суть которого определяется так: ПК более
высокого уровня не должны зависеть от компонентов более низкого уровня – они должны зависеть от абстракций; абстракции
не должны зависеть от частностей и деталей – частности и детали должны зависеть от абстракций. Собственно, очевидно, что
данный принцип упрочивает суть слабого зацепления, однако
в его рамках происходит также некоторая конкретизация специфики внутрисистемных связей между ПК. Его практическая
значимость характеризуется известным уровнем широты и заключается она как в упрощении повторного использования компонентов и предотвращения возможных системных ошибок, так
и в улучшении читабельности кода и ранжировании ПК в рамках системы по значимости. Еще более важен тот факт, что
в рамках данного принципа, как раз за счет вышеупомянутого
ранжирования, вводится обоснование для «правильной» зависимости – зависимости от абстракций, которые, как мы уже знаем,
являют собой наиболее значимые характеристики сущности
(в данном случае – программной системы). По сути, здесь подразумевается демаркация системы на некоторый незыблемый
системный каркас, который, соответственно, и представлен абстракциями, и на «остальные» ПК, которые должны быть легко
заменяемы или столь же легко изменяемы с учетом необходимой подстройки под актуальную ситуацию или, в более узком
смысле, задачу. Это прямым образом коррелирует со спецификой предполагаемого нами абстрактного паттерна.
121
После разбора структурных принципов также кратко охарактеризуем основные из организационных. Сразу следует сказать, что организационные принципы ООП касаются в первую
очередь стилистических и интерфейсных аспектов программирования и их ответственность заключается в максимальной
унификации программного кода, увеличении его читабельности, упрощении повторного использования и облегчении пользовательского взаимодействия с программным обеспечением.
Очевидно, что с точки зрения целеполагания наблюдаются пересечения с ответственностью принципов структурных, однако
специфика достижения заявленных целей вовсе иная. Т. е., если
структурные принципы апеллируют к сути формируемой
программной системы, ее ключевым архитектурным особенностям и абстрактным сущностям, то принципы организационные регламентируют специфику написания программного кода
с точки зрения стилистики, а также формирование внешнего
интерфейса программной системы – UI (User Interface).
К основным организационным принципам ООП можно отнести следующие:
KISS – «Keep it simple, stupid!» – «Будь проще!». KISS-принцип изначально был введен в среде инженеров-авиаконструкторов, и его определение вполне точно отражает суть: всегда решать проблему как можно более простым способом. Принцип,
при его соответствующей реализации, существенно облегчает
читабельность кода, а также интуитивное понимание интерфейса создаваемого приложения.
SLAP – «Single level of abstraction principle» – «Принцип единого уровня абстракций». Принцип гласит, что функции некоторого отдельного уровня не должны выполнять задачи иного
(более высокого или более низкого по отношению к своему «основному») уровня «задачности», а для реализации дополнительной функциональности следует формировать новые ПК на соответствующем уровне системы. Данный принцип, по сути,
детерминирует подразделение кода на множество уровней и подуровней, обуславливая данную демаркацию степенью абстракции и рамками ответственности ПК. Дополнительно стоит от-
122
метить, что из сущности данного принципа следует его некоторая двойственность, т. е. SLAP в несколько большей степени
ближе к структурным принципам, чем остальные из организационных. Однако все же он идентифицируется как организационный по причине некоторой недостаточности в плане фундаментальности.
DRY – «Don’t repeat yourself» – «Не повторяйся». Согласно
этому организационному принципу, необходимо избегать дублирования. Причем здесь ситуация уже становится дискуссионной: некоторые исследователи утверждают, что необходимо избегать дублирования вовсе, т. е. дублирования как логики, так
и данных; другие же настаивают только на необходимости отсутствия дублирования данных. Данный принцип, хоть это сразу и не очевидно, пересекается с одним из структурных принципов, а именно – с принципом разделения интерфейсов. Т. е.,
к примеру, если в рамках программной системы один и тот же
участок кода несколько раз используется (не логика повторно
используется, а именно схожие по логике участки кода используются несколько раз) для обработки данных, то целесообразно
инкапсулировать эту логику в отдельный ПК, чтобы затем при
необходимости предоставлять возможность повторного использования кода. Подобный подход с практической точки зрения
существенно упрощает внесение изменений, которые, при корректной реализации принципа, необходимо будет вносить однократно, а не множество раз.
YAGN I – «Your aren’t gonna need it» – «Тебе это не понадобится». Суть данного принципа заключается в превентивном
устранении возможной избыточности функционала программной системы. В этом контексте принцип пересекается с предыдущим организационным принципом, а также с разделением
интерфейсов. Он подразумевает пресечение возможных попыток
преждевременной разработки не требующейся на данный момент функциональности в рамках программной системы, так
как реализация подобных действий может привести к массе нежелательных последствий, среди которых, к примеру, сложность
внесения изменений. Здесь стоит отдельно заметить, что, как за-
123
частую происходит в парадигме ООП, данный принцип методологически противоречит одному из также немаловажных (но
здесь отдельно не упомянутых) шаблонов распределения ответственностей из GRASP-концепции – шаблона (на самом деле
паттерна, а шаблон в данном случае – употребляемый идентификатор) под названием «Устойчивость к изменениям» (Protected
Variations), суть которого заключается в превентивном определении точек возможных изменений или нестабильностей и соответствующем создании стабильной архитектуры вокруг них.
На данном этапе становится видна важность соблюдения баланса между крайностями в контексте принципов ООП, причем
важность диалектична, в том смысле что представляет собой
естественный пример единства и борьбы противоположностей.
В целом же можно сказать, что система принципов ООП также
является довольно самодостаточной, целесообразной, практикоориентированной, функционирующей по законам с естественными основаниями, не лишенной некоторых некритичных
внутренних противоречий. Вполне вероятно наличие в ней определенных проблем, что логично ввиду естественных оснований,
однако некие ярко выраженные и обозначенные преграды на
пути к созданию сильного ИИ отсутствуют.
Выводы по главе 9
В главе рассмотрены основы ООП. Было указано, что данная
парадигма детерминирована потребностью уравнивания в правах данных и методов для работы с этими данными, что привело от наличия разнородных потенциалов к формированию четко
оформленной структуры – объекта. Было показано, что объект
и вся его специфика определяются классом – более формальной
структурой, которая представляет собой наиболее общий способ описания ПК, полностью определяющий его состояние, поведение и идентичность.
Были актуализированы наиболее фундаментальные аспекты
ООП, среди которых инкапсуляция, полиморфизм, наследование, абстракция и интерфейс.
124
Инкапсуляция нами определена как способность связать в рамках единого ПК (к примеру, класса) информацию и способы
взаимодействия с этой информацией, и далее завуалировать специфику их взаимодействия.
Полиморфизм определен как способность ПК одного и того
же класса быть успешно реализованными в принципиально разных контекстах, но с сохранением единого интерфейса для всех
возможных контекстов.
Интерфейс обозначен как совокупность «входных точек» отдельного класса, т. е. всех его публичных данных и публичных
методов для работы с этими данными.
Наследование же – это способность к «продолжению рода»
с сохранением в «потомках» характерных особенностей «предков» в той или иной степени. В контексте ООП понятие наследования аналогично классическому пониманию.
Под абстракцией же мы условились подразумевать наиболее
значимые и характерные особенности какого-либо ПК.
Из определений вышеназванных понятий нами были проведены глубокие аналогии с естественной организацией систем,
и было показано, что ключевые особенности ООП дублируют
фундаментальные аспекты макромира.
Далее были рассмотрены фундаментальные принципы ООП,
которые разделены нами на две группы: структурные принципы
и организационные принципы. Было установлено, что структурные принципы вводят некоторый протокол построения ПК.
И к этой группе нами отнесены два наиболее общих и базовых
принципа ООП: принцип сильной связности и принцип слабого
зацепления.
Указано, что принцип сильной связности регламентирует
внутреннюю организацию ПК, а принцип слабого зацепления
определяет специфику связей между различными частями программной системы. Было выявлено, что все остальные принципы ООП просто дополняют эти два фундаментальных принципа.
Также к структурным принципам отнесены все пять принципов группы SOLID, которые конкретизируют сильную связность и слабое зацепление. Охарактеризованы все принципы
данной группы.
125
Принцип единственной ответственности обозначен как определяющий внутреннюю организацию ПК в плане сосредоточенности на некой единой задаче в противовес диссипативности
функционала.
Принцип открытости-закрытости определяет готовность компонентов к некоторым изменением и неготовность к иным.
Принцип подстановки Барбары Лисков уточняет, что наследующие компоненты должны только дополнять, а не трансформировать базовый функционал родительского компонента.
Принцип разделения интерфейсов гласит об избыточности
функционала любого ПК в плане наличия у него только необходимых данных и функций.
А принцип инверсии зависимостей уточняет тот факт, что
по возможности зависимости должны устанавливаться только
лишь от абстракций.
Далее были уточнены организационные принципы, которые
регламентируют в основном стилистику разработки. К ним отнесены: DRY – принцип, гласящий о повторном использовании
ПК, в противовес построению одинаковых; KISS – принцип,
четко указывающий на необходимость формирования наиболее
возможно простой логики ПК, в противовес чрезмерной сложности; SLAP – принцип соблюдения единого уровня абстракций
при построении ПК; YAGN I – принцип, определяющий полезность отсутствия преждевременной оптимизации ПК по причине частого отсутствия необходимости подобных действий.
В целом же нами было выявлено, что парадигма ООП обладает достаточной шириной и глубиной функционала для осуществления попытки формирования при помощи ее инструментария систем сильного ИИ в соответствии с предлагаемым нами
технотропным подходом.
Глава 10
ОБЩИЕ ПОЛОЖЕНИЯ ПОНЯТИЯ ПАТТЕРНА В ООП
10.1. Понятия паттерна, шаблона и алгоритма
После рассмотрения и переосмысления ключевых особенностей ООП, а также структурных и организационных принципов
этой парадигмы мы на данном этапе исследования вывели ее общую естественность, умеренную и некритичную внутреннюю
противоречивость, обширность предоставляемых ею возможностей и отсутствие как явных, так и латентных «указаний» на невозможность создания системы сильного ИИ при помощи ООП.
Более того, не было выявлено сущностных противоречий парадигмы ООП с предлагаемым в рамках исследования концептом
самоорганизующегося паттерна, который, согласно нашей гипотезе, способен в перспективе предоставить интеллектуальной
системе возможность для возникновения феномена технотропного сознания.
В свете введения предлагаемого нами концепта в контекст
текущего исследования ранее были упомянуты некоторые уже
существующие и подробно задокументированные решения из
области проектирования программного обеспечения, решения,
применяемые для самых различных целей и задач, а не только
в контексте разработки систем ИИ. А именно – «Абстрактная
фабрика» и «Шаблонный метод» из числа паттернов «Банды четырех». Было упомянуто, что суть предлагаемого нами концепта некоторым образом коррелирует с методологическим синтезом двух вышеупомянутых паттернов, разумеется, с некоторыми
оговорками и дополнениями. Таким образом, в сфере разработки ПК присутствует некоторое количество уже имеющихся «готовых» вариантов реализации определенного проекта с весьма
127
широким тематическим спектром. Вопреки возможному «изобретению велосипеда» мы считаем целесообразным глубже ознакомиться с возможностями, предлагаемыми исследуемой сферой.
И именно из этого мы выводим актуальность как практического,
так и теоретического осмысления оговоренных ПП программной продукции, а также данного феномена.
Постулируя с наиболее общих позиций, можно определить,
что в контексте необходимости решения той или иной задачи,
какой именно бы она ни была и к чему именно бы ни относилась, наличествует, как правило, некоторый набор возможных
вариантов этих решений. Наиболее успешные, удачно спроектированные, масштабируемые и гибкие из этих вариантов закрепляются в предметной сфере и получают некоторую «презумпцию оптимальности», которая актуальна до тех пор, пока не
будет внедрено решение лучше. Говоря более формально, такого
рода варианты определяются как последовательности действий,
направленные на решение определенной задачи. И называются
они «паттерны» (patterns).
Паттерны являются весьма распространенным явлением
в большинстве сфер человеческой деятельности, и область программирования, соответственно, тут не является исключением,
а, напротив, отличается довольно-таки высоким уровнем развития и распространения «паттернизации». Не в последнюю очередь по той причине, что концепция паттернов и предоставляемые
ею возможности отличаются удобством в контексте унификации дискурса в среде разработчиков и проектировщиков программных систем, а также в плане более глубокого понимания
действий друг друга в той или иной ситуации разработки.
Для примера. При отсутствии понятия паттерна разработчикам приходилось бы заново объяснять и обосновывать смысл
своих действий, что занимало бы продолжительное время. В особенности сильно это тормозило бы процесс на этапе определения стратегии разработки того или иного технологического решения, а также на этапе принятия решений о внедрении той или
иной «фичи». При наличии паттернов же дискурс становится
тезисным, а программные и архитектурные решения – куда бо-
128
лее интуитивно понятными. И это только один пример из многих возможных (помощь отдельно взятому разработчику в контексте необходимости решения какой-либо задачи, избегание
в проектировании «плохих» паттернов и т. д.). С другой стороны, необходимость обоснования целесообразности применения
паттернов в сфере разработки программного обеспечения как
таковая отсутствует по той причине, что, как уже говорилось,
специфика самой сферы отличается довольно высоким прагматизмом и «то, что не полезно» там просто не оседает.
Отдельно следует заметить, что при всей практической значимости паттернов они, будучи навязаны как обязательные к исполнению и реализации, теоретически, могут создавать эвристические рамки. Однако для того, чтобы уточнить, так это или нет
или насколько это так, следует глубже ознакомиться с тематикой.
В первую очередь следует отметить терминологическую путаницу с понятиями «паттерн» (pattern) и «шаблон» (template).
Некоторое недопонимание порой возникает в дискурсе исследователей и разработчиков как в отечественном сообществе, так
и за рубежом. Суть этой путаницы заключается в сложности однозначной интерпретации иностранных текстов, неоднозначности определений обоих понятий, их некоторой синонимичности
вплоть до взаимозаменяемости, а также определенной сущностной неоднозначности и т. д. Мы, в свою очередь, постараемся
разделять данные понятия.
Паттерны будем определять как выявленные закономерности последовательности действий в каком-либо контексте, направленные на решение некоторой задачи, имеющей один или
более вариантов решения.
Шаблон определим как некоторый эталон, по «образу и подобию» которого создаются определенные «изделия» со степенью отличия от эталона в строго ограниченных рамках по контексту и вариантам.
Разумеется, при необходимости в данных определениях можно усмотреть некоторые пересечения, схожести и так далее, однако, по нашему мнению, они все же наличествуют в меньшей
степени, чем различия. Фундаментальное же различие между
129
паттерном и шаблоном заключается в том, что, в то время как
паттерн в упрощенном варианте представляет собой последовательность взаимосвязанных действий и его сутью именно эти
действия и являются, шаблон никаких действий не подразумевает – он просто есть и, как следствие, пути, способы и варианты воспроизведения своего «образа и подобия» в самом себе не
несет, так как совершенно неважно, каким именно образом он
будет «достигнут».
Также необходимо отдельно осветить еще одну сугубо концептуальную проблему с понятием паттерна, а заодно упрочить
отличие от понятия шаблона. А именно – как можно уловить,
в том числе и по нашему определению, паттерны с некоторой
частотой путают с алгоритмами, и опять же, вплоть до полной
взаимозаменяемости этих понятий. Само собой разумеется, что
подобное не вполне корректно. Детерминанты данной проблемы
вполне очевидны и заключаются они в некоторой (порой довольно существенной) схожести сути паттерна с сутью алгоритма:
в обоих случаях подразумевается выявленная и зафиксированная последовательность определенных действий, направленных
на решение некоторой проблемы.
Наиболее общее определение алгоритма можно сформулировать так: алгоритм – это набор последовательных действий,
направленных на решение какой-либо задачи за определенное
конечное время. Можно также детализировать суть и определить
куда более формально: «…алгоритм – это точно установленное
предписание (инструкция) о выполнении в определенном порядке некоторой последовательности операций, однозначно ведущих к решению той или иной конкретной задачи. Подразумевается, что результат выполнения алгоритма напрямую зависит от
исходных данных: т. е. один и тот же алгоритм при разных исходных данных даст разные результаты; с другой стороны, если
одному и тому же алгоритму передать несколько раз одни и те
же данные, он должен столько же раз выдать один и тот же результат» [117].
Как из первого, так и в особенности из второго определения
заметны некоторые ключевые аспекты природы алгоритмов,
130
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]