Дмитрий Сахань
Не кажется ли вам, что нынче программирование интеллекта уперлось в непреодолимую стену? Тогда давайте для начала порассуждаем об эволюции самого программирования. На заре развития (история гораздо глубже, но мы начнем от первых Бейсиков) программирование ограничивалось простым командным программированием. Не было понятия процедур и функций, были только переменные и операторы, то бишь команды. Код программы выглядел в виде пронумерованного списка инструкций. Единственной на тот момент командой перехода между строками исходного кода был оператор GOTO. Безусловно, очень скоро возможности командного программирования исчерпались, нужно было расширить его рамки.
Первой ласточкой процедурного программирования явился оператор GOSUB – вызов подпрограммы. Но это еще не было процедурное программирование в чистом виде. Был лишь факт, что шаг сделан в правильном направлении. Через короткое время идея вызова подпрограмм оформилась в вызовы функций и процедур, а программирование стало называться процедурным. Основная фишка такого подхода заключалась в том, что процедуры и функции могли принимать большое количество входных параметров, то есть код процедур уже не обязательно должен был привязываться к именам глобальных переменных. Вместе с этим родилось понятие глобальных и локальных (доступных только внутри процедуры) переменных. Кроме того функции могли возвращать результат выполнения в вызвавшую их точку исходного кода. В свою очередь это привело к возможности рекурсивного программирования (когда функция вызывает саму себя N раз, анализируя свой же возвращаемый результат), которое по сути дела является стилем процедурного программирования, а не отдельным программированием. Еще с появлением процедурного программирования отпала необходимость нумерации строк программы, так как функции и процедуры имели свои имена и могли свободно располагаться в любом месте кода (нумерация же строк привязывает фрагмент кода к определенному местоположению в исходном коде).
Программисты быстро оценили новый подход и бросились использовать его возможности. Еще через время стали заметны изъяны и в нем. Все больше усложнялись программы, все сложнее становилось управлять возрастающим количеством переменных, все четче проглядывалось "родство" между некоторыми переменными, все сильнее разбухали строки входных параметров процедур. И вот кому-то пришло на ум объединить родственные переменные в структуры, а новое программирование получило название структурного или, другими словами, ориентированного под структуры. Тут же появились понятия структур (иногда их называют записями), а также содержащихся в структурах полей данных, указателей на структуры (чтобы не тащить содержимое структуры через стек) и такого прочего. Существенный плюс заключался в возможности вложить в структуру другие структуры, в которые, в свою очередь, могли быть вложены еще какие-нибудь структуры. Теперь процедура могла принимать во входном параметре всего одну переменную (структуру), а уже из нее извлекать любые вложенные данные (поля). Сразу же сложилась удобная практика указывать требуемое поле, перечисляя через символ точки (в языке Си через "->") полный путь к полю внутри структуры.
AgeData = record // объявление структуры (AgeData)
Birth: String //
Dead: String //
end
Worker = record // объявление следующей структуры (Worker)
Name: String //
Age: AgeData // в ней находится вложенная структура типа AgeData
Address: String //
Remark: String //
end
var
A: Worker // объявление переменной со структурой типа Worker
begin
A.Name = "Петя Иванов" // доступ к нужному полю через символ точки
A.Age.Birth = "01 января 2000" // доступ к нужному полю через символ точки
print(A.Name) // доступ к нужному полю через символ точки
end
Удобства структурного программирования казались поразительными, пока программисты не натолкнулись на следующий непреодолимый барьер. Многие структуры обрабатывались одними и теми же процедурами, но сами процедуры оставались разрозненными. То есть в новую программу набирались (по частям) уже отлаженные процедуры из прошлых программ. При большом количестве процедур их перенос в новую программу не казался простым делом, так как нужно было перенести все, что могло понадобиться для используемой структуры. Поначалу проблема решалась переносом часто используемых процедур в отдельные модули (файлы), из-за чего даже появился термин "модульное программирование". Однако не все оказалось так просто. Выяснилось, что определенные поля в структурах должны бы иметь прямую зависимость от конкретных процедур. Причем зависимость была такова, что не поле изменялось процедурой, а при изменении поля должна была быть вызвана процедура.
С развитием графических интерфейсов ситуация прояснилась за счет того, что элементы оформления хорошо ассоциировались с отдельными объектами. Именно наблюдая за кнопочками, меню, списками и тому подобным программисты отметили, что на определенное действие "объект" должен отвечать каким-либо событием, а само действие чаще всего сводится к изменению некоторого свойства "объекта". Далее было отмечено, сколь незначительна разница между определенными структурами и процедурами, как следствие, разумно было отнести их к одним и тем же классам действий. Таким образом, в программировании появилось понятие классов. Это было уже не просто кодирование процедур и структур в одном модуле, а планомерное связывание процедур со структурами. Изюминка была в том, что вроде бы обычная структура включала внутрь себя подходящие ей процедуры. Фактически, переменной структурного типа можно было помимо изменения какого-то ее поля еще и дать команду что-то выполнить. В результате структура превращалась в объект, а новое программирование стало называться объектно-ориентированным программированием (ООП).
Теперь объявляемая переменная такого вот нового структурного типа стала называться объектом, а исходный код "структуры" стал называться классом. Соответственно в ООП понятие "переменная такого-то структурного типа" звучит как "объект такого-то класса". Кстати, в ООП остались и просто структуры, так как никто не собирался отказываться от дополнительных возможностей структурного программирования. В дальнейшем классы доработали связью между отдельными полями класса (бывшей структуры) и его процедурами, а связанные поля стали именовать свойствами. В итоге объект стал в состоянии не только выполнять определенные "команды", но и делать запрограммированные действия при изменении его свойств (полей). В конечном счете, родились понятия свойств, методов и событий объекта (класса). Под свойством понималась внутренняя переменная объекта, при изменении которой вызывалась та или иная внутренняя процедура. Очень положительно, что еще одну процедуру можно было назначить свойству в случае попытки чтения из него. Под методом понималась определенная внутренняя процедура, которую можно было вызывать напрямую. События – в принципе, те же методы, только вызываемые автоматически при определенных действиях с объектом.
Worker = class // объявление класса (Worker)
Name: String // поле (переменная) внутри класса
Birth: String // поле (переменная) внутри класса
Age: String // поле (переменная) внутри класса
//
procedure Create // процедура (метод) внутри класса
procedure ComputeAge // процедура (метод) внутри класса
procedure Destroy // процедура (метод) внутри класса
end
var
A: Worker // объявление объекта класса Worker
begin
A.Create // выполнить Create – это метод объекта
A.Name = "Петя Иванов"
A.Birth = "01 января 2000"
A.ComputeAge // вызывается еще один метод объекта
print(A.Name)
end
Неудивительно, что классы можно внедрять внутрь других классов, можно наследовать классы (то есть порождать новые), можно разделять свойства, переменные и методы класса по степеням доступа к ним (личные, защищенные, общедоступные). Все это породило настоящий взрыв в технологиях программирования. Переменные-объекты вдруг ожили – сами реагируют на внешние события, сами делают все, что им указано. Программист, вызывающий метод объекта или меняющий какое-то его свойство, может совсем не задумываться, с какими внутренними действиями это связано. Дал команду – получил результат, и знать не надо, что там к чему и как оно работает.
Методы как классы методов
В настоящее время программирование остановилось на ООП, но все явнее чувствуется следующий барьер. По истории программирования можно было заметить, как переменные превратились в структуры, а те в свою очередь в объекты. Долгое время объекты удовлетворяли программистов, пока дело не дошло до разумных (с точки зрения разума вообще) действий. Вроде бы в объектах больше ничего не придумаешь, и все же что-то должно измениться. Сейчас тяжело представить, какой вид примут "разумные" объекты. Большую проблему представляет самостоятельная перестройка работы объекта. Здесь обычными свойствами и методами проблему не решить. Дело в том, что разумный организм умеет адаптироваться к окружающим условиям, то есть менять алгоритмы своего функционирования. Еще сложнее, что методы "разумного" объекта вообще могут не задаваться явно в момент создания объекта, они могут быть "сконструированы" объектом потом в результате его опыта. Естественно, должны быть какие-то базовые методы, из которых в дальнейшем собирается удовлетворяющая конструкция-метод.
Большое значение имеет соотнесение метода с самостоятельным классом. То есть класс методов, а не класс объектов. Тут немного другое понятие, и пока слишком призрачно представляется, как должен выглядеть класс методов. В качестве примера можно привести класс методов поиска разумного организма. Когда, например, человеку говорят: "Найди что-то там-то", фактически, называют класс методов, ко
И снова вернемся к примеру с разумным организмом. Двигать ногой – это базовый метод человека, данный ему от природы. Двигать ногой вправо, влево, вперед, назад – это приобретенные методы, так как человек по мере развития узнает, где какие направления. К тому же двигать можно по-разному – с поднятой стопой, наклоненной и так далее. Идти – это тоже приобретенный метод, но он включает в себя целое семейство методов по движению ног.
Вообще "класс методов" – не родня понятию "класс объектов", поскольку здесь вступают в силу другие правила, хотя в общих чертах схожесть есть. В обычных объектах методы тоже могут быть похожими на многомерные, ведь программист может вызвать метод предка (класс, от которого был порожден данный класс), только там программист принудительно указывает, чей именно метод должен быть выполнен, здесь же "разумный" объект выбирает необходимый метод сам. Прибавьте сюда и то, что методы могут конструироваться по ходу работы объекта. Методу можно, например, как бы сказать: "Идти туда-то – это делается так-то и так" или "Идти туда-то – это идентично такому-то действию за исключением таких-то моментов". В свою очередь метод самостоятельно расширяет свою многомерность. Само же понятие конструируемого метода указывает на отличительный способ функционирования. Код объекта в ООП компилируется, и потом алгоритм его методов не может изменяться. А раз "разумный" объект может адаптировать свои методы, значит, должен быть некий формат описания алгоритмов несуществующих (конструируемых в ходе работы) методов.
Попробую объяснить взаимодействие классов методов на наглядном примере. Допустим, у нас есть некоторый объект "А". Пусть объект находится в двумерной плоскости, разделенной на клетки. Одна из клеток помечена красным цветом. Объект видит клетки (вдоль линии взгляда) только перед собой. Объект может поворачиваться на 90, 180 и 270 градусов вправо или влево. Объект может шагать на одну клетку вперед. Задача объекта "А": найти красную клетку, чтобы она оказалась в любой клетке прямо перед ним.
Понятное дело, у объекта должны быть хоть какие-то базовые методы. В данном случае это будет "Двигаться вперед", "Повернуться", "Вижу ли заданную клетку" и "Достигли ли края плоскости". И вот, что теперь происходит.
Подключить к объекту метод "Двигаться вперед"
Подключить к объекту метод "Повернуться"
Подключить к объекту метод "Вижу ли заданную клетку"
Подключить к объекту метод "Достигли ли края плоскости"
Если перечисленные методы вроде бы (позже объясню, почему "вроде бы") относятся к базовым, то теперь нужен конструируемый метод "Найти клетку". Фактически, мы должны научить объект, как ему искать клетку. Для этого представим, что у нас уже разработан некий формат описания алгоритмов конструируемых методов. Смотрим, что происходит дальше.
1. Создать метод "Найти клетку" и подключить его к объекту
2. Вложить в метод "Найти клетку" методы "Двигаться вперед",
"Повернуться", "Вижу ли заданную клетку" и
"Достигли ли края плоскости"
3. Методу "Найти клетку" присвоить, например, такой алгоритм:
Цикл, пока по методу "Достигли ли края плоскости" не достигли ее
вызвать метод "Двигаться вперед"
Конец цикла
...
...
вызвать метод "Повернуться на 90 градусов вправо"
...
...
Цикл, пока по методу "Достигли ли края плоскости" не достигли ее
Если по методу "Вижу ли заданную клетку" не видим ее, тогда
вызвать метод "Повернуться на 90 градусов вправо"
вызвать метод "Двигаться вперед"
вызвать метод "Повернуться на 90 градусов влево"
Иначе
Клетка найдена
Конец если
Конец цикла
...
...
вызвать метод "Повернуться на 180 градусов"
...
...
Цикл, пока по методу "Достигли ли края плоскости" не достигли ее
Если по методу "Вижу ли заданную клетку" не видим ее, тогда
вызвать метод "Повернуться на 90 градусов вправо"
вызвать метод "Двигаться вперед"
вызвать метод "Повернуться на 90 градусов влево"
Иначе
Клетка найдена
Конец если
Конец цикла
...
...
и так далее
Теперь мы можем обращаться к методу "Найти клетку", уже принадлежащему объекту "А", то есть вызов типа "А.Найти клетку(допустим, на некоторой плоскости Z)". А что же будет, если объект "А" каким-то образом попадает из плоскости на другую фигуру, например, куб? Очевидно, метод "Достигли ли края плоскости" будет непригоден для поверхности куба. Теперь нам нужно иметь либо базовый метод "Достигли ли края поверхности куба", либо создать такой метод, как мы создали метод "Найти клетку". А как только мы создали (или имеем его в качестве базового) нужный метод, мы должны расширить N-мерность метода "Найти клетку", спрятав в этом методе еще один алгоритм поиска, но уже для куба.
Расширить метод "Найти клетку" (то есть добавить в метод еще один
алгоритм поиска), а в качестве алгоритма взять "плоскостной"
алгоритм (предыдущий алгоритм), только в нем использовать
метод "Достигли ли края поверхности куба", а не "Достигли ли
края плоскости"
Теперь уже объект "А" способен искать клетку и на плоскости и на поверхности куба (например, "А.Найти клетку(на некотором кубе Z)"), используя всего лишь один метод "Найти клетку". Разумеется, в данном методе скрывается два алгоритма, но из объекта "А" виден только один единственный метод, сколько бы в нем ни скрывалось алгоритмов. Этот пример, конечно, поднимает вопрос о том, как метод должен определять, какой алгоритм использовать. То ли это будут входные параметры для метода, то ли ему будет передаваться объект, на котором будет выполняться метод. Пока этот вопрос открыт, потому что нет еще ни одной спецификации, ни одного формата описания алгоритмов конструируемых методов. Я же перейду к объяснению моего "вроде бы", употребленного ранее в отношении базовых методов.
Как и в только что описанном случае с наличием базового или впервые создаваемого метода для куба, так и в случае базовых методов объекта "А" (методы "Двигаться вперед", "Повернуться" и так далее) приемлем вариант, когда эти методы не были базовыми, а создавались в процессе функционирования объекта "А". К тому же даже базовые методы могут расширять свою N-мерность, ведь они - тоже классы методов. Если, к примеру, объект "А" по каким-то причинам потерял ноги, и его пересадили в инвалидное кресло, то метод "Найти клетку" продолжает исправно работать, потому что базовые методы "Двигаться вперед" и "Повернуться" все равно выполняют свою задачу. А это происходит за счет того, что указанные методы расширяют свою N-мерность дополнительными алгоритмами (ведь кто-то все равно вынужден будет обучить методы новым алгоритмам), что двигаться вперед на кресле – это так-то и так, поворачиваться – это так-то и так. Собственно, на остальные методы объекта "А" никак не влияет его "физическое уродство".
Если вдруг объект дошел до воды, то метод "Найти клетку" опять работает, ведь метод "Двигаться вперед" расширяется новым алгоритмом, что плыть по воде – это так-то и так, задействуются такие-то и такие методы (например, "Грести руками"). Естественно, новые методы типа "Грести руками" добавляются в объект и обязательно вкладываются внутрь метода "Двигаться вперед". Если у объекта не окажется руки (допустим, будет протез), то N-мерность метода "Грести руками" расширится новым алгоритмом "гребка" протезом, остальные же методы будут продолжать работать так, как нужно.
Если перед объектом окажется стена, то расширится метод "Двигаться вперед", потому что теперь двигаться – это "Перелезть через стену", а перелезть через стену – это сделать так-то и так. В принципе, это касается любого метода, так как я приводил примеры с методами движения объекта, поскольку они нагляднее. Так, например, если мы ищем красную клетку далеко от себя (или совсем на чужой поверхности, или совсем не красную клетку), то метод "Вижу ли заданную клетку" расширится новыми алгоритмами, что видеть далеко от себя – это, к примеру, взять бинокль, навести резкость, посмотреть в него и так далее.
Думаю, вам стал понятен смысл взаимодействия методов. Объекты объектно-ориентированного программирования в основном представляют собой усовершенствованные переменные, где серьезные изменения затронули по большей мере именно структуру переменных, лишь самым простым образом "втащив" в объекты так называемые методы, ранее бывшие обычными функциями и процедурами. Теперь наступило время серьезных изменений в методах объектов. Как мне кажется, как раз по этому пути пойдет разум-ориентированное программирование.