Предыдущая страница реферата | 1  2  3  4  5 | Следующая страница реферата

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  4  5 | Следующая страница реферата