Литература 1. С.Бобровский. Самоучитель
программирования на языке С++ в системе Borland C++ Builder 5.0 2.
А.Я.Архангельский. Программирование в C++Builder
1. Проба на язык
Во всяком деле следует определиться с целью. Цель при этом может быть как
определенной, так и сколь угодно неопределенной. Наконец, цель в процессе работы
конкретизирует как свои формы, так и способы своей реализации. Настоящей
нашей целью является создание модели бесконечно развивающейся машины, с которой
мы находимся в отношении диалога и цель (результат) процесса этих отношений с
нею состоит в преобразовании субъективных схем в машинные модели, то есть в
передаче субъективных функций функциям машины. Как это и имеет место у человека:
в процессе его отношений с внешней средой у него формируются
инстинктивно-рефлекторные стереотипы.
Пусть есть объекты одного рода.
Они модифицируются и различаются благодаря форме, становясь видами рода. Формой
объектов определяются их свойства и методы (формы действия (поведения)).
Исходное представление, с которого мы начинаем, состоит в
противопоставлении субъекта какому-то множеству чувственно определенных
объектов, которые вместе образуют систему, с которой мы находимся в отношении
диалога. В то же самое время, возможно, мы можем обращаться к каждому из
объектов системы. Для того, чтобы попытаться разобраться с тем, как это и
насколько возможно это сделать средствами объектно-ориентированного
программирования, мы рассмотрим идеологию построения программы на примере
игры в кости, приведенной в книге С. Бобровского.
Итак, существует реальность G и субъект S, отношения между
которыми определяются как отношения игры, на одной стороне которой находится S ,
на другой - программа компьютера. I. Правила
игры:
1. Отношения между игроками начинаются в начальной точке с нолем
очков у каждого. Очки, следовательно, выражают собой вес каждого из игроков
относительно друг друга. В начале игры у них равный вес. 2.Ходят по
очереди. Как это по жизни и происходит: каждое действие вызывает ту или иную
реакцию, хотя бы реакция эта и была равна нолю. На каждом
шагу игроки бросают кость. Иначе говоря, всякое действие, которое мы
осуществляем, представляет собой своеобразную кость, поскольку действия содержат
в себе неучтенные компоненты, и неизвестно, выиграешь в результате действий или
проиграешь. Т.о. в игре присутствует случайный компонент, моделируемый костью
3.Если в результате бросания выпадает число от 2 до 6 включительно, то игрок
решает, будет ли он продолжать серию бросков. Если "да", то очки приписывают к
уже набранным в текущей серии бросков, и он бросает кубик; если нет, то число
очков добавляется к его общему активу, и он передает ход. Если при броске кости
выпадает единица, то накопленные очки во время текущего хода теряются и ход
передается противнику. Т.о., неопределенности, связанной с костью,
противопоставляется произвольное решение игрока. 4. Выигрывает первым
набравший по крайней мере 100 очков.
Итак, первым шагом является прояснение
вопроса об общих закономерностях, которые должна выполнять машина.
II. Элементы управления Второй этап -
создание пользовательского интерфейса, в который будут помещены элементы
управления. Другими словами, мы еще ничего не сделали, но начинаем строить
элементы управления в соответствии с правилами отношения с реальностью. До
сборки двигателя, шасси и т.д. автомобиля мы должны озаботиться о руле, педалях,
панели приборов. То есть мы должны определиться, что именно мы должны будем
знать о состояниях машины, и посредством каких механизмов будем управлять ею.
Разумеется, при построении развивающейся машины необходимо иметь возможность
дополнять органы управления
Начнём с определения той информации, которую нужно иметь для
того, чтобы вести игру. Какой здесь должен быть заложен принцип? - память должна
быть не в нас, а вне нас. Вообще информация, которая касается двух
противоположных сторон, должна быть представлена. В каждый момент игры мы должны
знать число очков человека и компьютера, а также число очков человека и
компьютера на текущем ходу. Также нужно знать, сколько очков выпало на кубике.
И, наконец, нужно знать число партий и соотношение очков в каждой из партий.
Действия, которые должны быть осуществлены: мы должны иметь возможность
начать игру и выйти из неё и должны продолжить ход или передать очередь хода.
Тогда, когда мы конструируем программу, мы должны отчётливо представлять
себе, какие действия будут предприниматься по ходу игры.
2. Адресация и ИРС
Когда речь идет об объектно-ориентированном программировании, то
объектная интерпретация - это всего лишь интерпретация, представление о
реальности программирования, которая в результате этого осуществляется. И между
интерпретацией реальности и реальностью программирования - дистанция "огромного
размера". Просто объектная интерпретация определенным образом накладывается на
реальное программирование, влияя на его структуру.
Но здесь есть и еще одна вещь: когда мы говорим об объектном
программировании, то нам представляется, что тем самым мы идем непосредственно
от реальности, забывая, что реальность - это вещь чувственная, представленная в
сознании в виде образов; сознание имеет дело с образами (отражением), а не с
реальностью, с последней имеют дело рефлексы, сознание должно преобразовать
образы в объекты и их свойства. Т.о., над реальностью образов должна быть
проведена работа, которая в качестве своего результата должна дать объектную
модель реальности.
И следующий момент, которому должны удовлетворять наши действия - это
такое построение модели, которое было бы привязано к общим принципам работы
компьютерного железа и реализующих его работу программ. А здесь важнейшим
принципом является принцип адресации, принцип, согласно которому мы должны иметь
возможность найти любой объект из множества объектов, с которыми имеем
дело. Итак, что бы мы ни делали, мы не должны упускать из вида
возможность адресаций и переадресаций. У нас должна существовать возможность
благодаря наличию адресов переходить при необходимости к любым объектам.
Как выглядят процессы адресации с рефлекторной точки зрения? Какими
характеристиками они обладают? Самое первое, адресации есть выделение объектов
не непосредственное, а по их признакам. Затем, адресации осуществляются по
представлению объекта и его определению, либо на основе поиска объекта с
заданными свойствами. В первом случае просматриваются существующие коды объектов
и среди них выбирается подходящий, во втором случае код есть, и осуществляется
выбор объекта, подходящий по своим свойствам коду. Так как объект отбирается по
его признакам, а объект и его признаки - не одно и то же, то такой отбор
объектов может содержать ошибки. При этом адрес формируется на
основе повторения связи между сигнальным и значимым раздражителями. Итак,
рефлекторная адресация формируется на основе статистической связи между двумя
раздражителями, один из которых выступает в роли сигнального, другой - в
качестве значимого.
Значимость же раздражителя связана с
доминирующим рассогласованием в системе, которое требует своего удовлетворения.
И, в этом смысле, инстинктивно-рефлекторная система характеризуется активностью,
обусловливаемой инстинктивной программой, формирующей рассогласования в системе,
которые требует своего удовлетворения посредством активности
инстинктивно-рефлекторной системы (ИРС). Но инстинктивная программа -
это программа, которая формирует рассогласования. И в качестве таковой она
является одной из программ, хотя и обладающей специфическим характером.
Рассогласование в ИРС вызывает активность системы,
которая ищет для себя предмет потребления, потребление которого снимает
рассогласование системы на тот период времени, на который его хватает.
Значит, следствием рассогласования является активность системы, выражающаяся в
ориентировочно-исследовательской реакции по поиску и узнаванию предмета
потребления, затем по присвоению этого предмета (присвоение = превращение в свою
собственность) и, наконец, его потреблению (потребление = превращение
существующего автономно объекта в часть организма или личности ИРС)
Возможно ли машинное моделирование этих процессов? Разумеется. В других статьях
речь уже шла о программировании рассогласований в системе. Как это выглядит?
Пусть система состоит из множества частей, каждая из которых существует не как
объект, хотя, разумеется, она является объектом, но как процесс, и, разумеется,
такая система также есть процесс. Всякий процесс для своего существования
требует пищи (в широком смысле). Показателем степени потребности в пище является
рассогласование. Механизм, посредством которого юстируется прибор, показывающий
степень рассогласования, является существенно условно-рефлекторным, и это -
отдельная тема. Показания такого прибора, указывающего на степень
рассогласования, должны считываться системой и при определенных его значениях в
системе возникает доминанта, направленная на удовлетворение возникшей
потребности. Эта потребность может носить самый разнообразный характер, от
потребности в пище до дефекации. В системе возникает напряжение, которое
система стремится снять посредством деятельности. В общем случае сигнал на
выполнение соответствующей деятельности формируется как разность между нормой и
величиной отклонения системы от нормы. Так как процесс приводит к непрерывным
изменениям, а в условиях многомодульной системы, которая в текущий момент
способна выполнять только одну форму деятельности, а психика человека обладает
именно этим свойством, непрерывные регулировки невозможны, то процессы
удовлетворения той или иной потребности осуществляются в отдельные дискреты
времени, причем, все эти вещи бывают приурочены к определенному времен, как,
например, приём пищи, или по достижении рассогласованием определенных величин.
Итак, мы имеем ИРС как объект-процесс; объекты-части ИРС и их
объективные процессы, характеризующие их состояния. При этом мы помним, что
действует ИРС как система в целом. Каждый из объектов-частей ИРС характеризуется
собственной сферой функционирования, однако он управляется целым; ИРС управляет
своими частями, получая информацию об их состоянии. В этом смысле мы имеем, с
одной стороны, состояния частей, но удовлетворяются они не непосредственно, а
опосредованно через ИРС. ИРС реализует свои действия, направленные на получение
питания для какой-то части путем синтетического управления действиями
множества своих частей.
3. Адресации и последовательность выполнения программы
Итак, первая задача в процессе ООП - это преобразование
образной реальности в объектную. И здесь, конечно, возникает вопрос об общих
принципах таких преобразований.
Так как мышление характеризуется тем, что то, что в чувственной
реальности рассматривается как объект - то есть как некоторая материальная
субстанция, некоторая сравнительно постоянно существующая отдельность, которая
может отделяться от других отдельностей благодаря возможности её перемещений в
пространстве, и обладает внешними признаками и какими-то способами
(воз)действий, и признаки и действия могут рассматриваться как свойства объекта,
то если подходить к этому с точки зрения уже сформированного рефлекса как своего
рода формального механизма, то если мы имеем объект, то имеем и набор его
свойств - признаков и действий. Так в визуальных компонентах мы имеем дело с
Properties и Events При этом то, что мы способны изменять модификации свойств и
определять события объектов, а также вызывать их, мы можем вполне вынести за
скобки. Важным является только то, что с любым из визуальных объектов
связывается набор его свойств в виде признаков и порождаемых нами посредством
определенных действий, например, кликом на мыши, программируемых нами действий.
Во всех этих случаях мы можем рассматривать себя в качестве творческой,
созидающей силы природа, а если это кому-то больше нравится, в качестве
божественной силы, создающей реальность. Так как природа - вещь чувственная, то
в ней мы не можем иметь дело с абстракциями: мы не можем взять в руки
абстрактный камень, но только чувственный конкретный камень. И мы не можем
обратиться к абстрактному объекту - но всегда к определенному, чувственному
объекту. Так как в мышлении конкретный, чувственный объект обозначается
посредством собственных имен, то это значит, что объекты, с которыми мы имеем
дело, должны иметь собственные имена. Но мышление человека не может
иметь дело с чувственностью. Оно имеет дело с абстракциями. За нашими действиями
с чувственными объектами стоит мышление. Мы либо от чувственности переходим к
мышлению либо от мышления - к чувственности. В некотором смысле, процесс
формирования рефлекса есть процесс мышления, процесс функционирования
сформированного рефлекса есть чувственный процесс. И в этом смысле оказывается,
что чувства - производная от мышления, а не наоборот (Но, разумеется, возможна
дополняющая приведенную противоположная точка зрения). Т.о. оказывается,
что всякий объект, с которым мы имеем дело, имеет двойное представительство - в
мышлении и в чувстве. В мышлении объект выступает в качестве абстракции, в
качестве общего понятия, в чувстве он выступает в качестве единичного объекта.
Т.о., например, имея дело с формой Form, мы получаем два объекта: форму как
общее понятие и форму как отдельный объект, причем, очевидно, что этот отдельный
объект подводится под общее понятие. Т.о. мы получаем выражения вида TForm и
Form, где TForm представляет общее понятие, а Form - единичный чувственный
объект. Мы получаем своего рода двуликого Януса: один и тот же объект
рассматривается как принадлежащий сфере мышления и, в то же самое время, с
другой стороны, реальности; с одной стороны, он есть нечто общее, с другой
стороны - объект, денотат (элемент объёма) имени как представителя понятия.
Простейший образ связи общего и частного и возможной адресации дает
идея дерева. Взяв за точку отсчёта вершину дерева, мы в конечном счете по
соответствующим путям можем перейти к единичному объекту. Например, если в
качестве исходного понятия возьмём "дерево", тогда, беря последовательно
основания, мы можем определить путь к единичному дереву и обратно. Например, вид
дерева, места произрастания, возраст и т.д. Однако при движении от общего
понятия ко всё более специфичным мы постоянно сталкиваемся с выбором, тогда как
если мы идем от частного к общему, то движение является однозначным. И еще: в
конце движения мы получаем то же самое, что имели вначале. Только на одном конце
у нас чувственный объект, признак существования (неважно, идеального или
материального), а на другом - общее понятие объекта. Любое из
возможных оснований даёт нам множество модификаций объекта, причем, основания
могут рассматриваться как контекст объекта, например, когда речь идёт о зонах
произрастания, либо как признак объекта, например, когда речь идёт о возрасте
дерева. Во всяком случае, должен быть фиксирован порядок применяемых оснований,
какое основание следует за каким, хотя можно было бы взять параллельно всё
множество признаков объекта и взять их пересечение. Но нас интересуют именно
адреса признаков объектов, а для этого удобным является принцип дерева. Возьмём
матрицу с n последовательно перенумерованными строками, которые могут иметь
разную длину, причем, как число строк, так и число элементов в них может быть
потенциально бесконечным. Тогда, полагая, что строки расположены
последовательно, можно сформировать путь от общего понятия к любому объекту, с
более или менее удовлетворительной точностью. Например, адрес объекта может
выглядеть как 35.789.13.12987..... и т.д., где точками отделены номера элементов
предыдущих строк от последующих. При этом степень точности "попадания в нужный
объект" возрастает по мере возрастания номера строки, если мы идем от общего к
частному, а как раз этот принцип лежит в основании рефлекса. В этом построении
нужно иметь ввиду, что когда мы говорим об объекте, то на практике нас
интересует не дынный единичный объект, а экземпляр объекта с заданными
свойствами. Поскольку дерево построено, противоположное
движение является однозначным. В то же самое время, если мы попытаемся от
объекта идти к общему, когда такой структуры нет, то вопрос подведения объекта
под основания оказывается не менее сложным. Итак, дерево позволяет
определиться с адресами любого объекта, и при этом адресом объекта является вся
цепочка значений каждого из оснований,
и не в коем случае не последнее основание последней строки. Множество возможных
путей оказывается представляющим собой множество объектов, поскольку даёт
пересечение всех оснований.
Теперь изменим образ и будем рассматривать
отношение части и целого. Например, автомобиль - это целое. Автомобиль состоит
из множества частей - кузова, шасси, двигателя и т.д. Каждая из этих частей, в
свою очередь состоит из множества частей и т.д. Как это может быть формально
представлено. Понятия части и целого являются относительными понятиями: нечто
является частью по отношению к целому, в которое оно входит, и является целым по
отношению к частям, из которых состоит. Особенностью частей целого является то,
что любая часть целого выполняет какую-то функцию в этом целом. И при этом не
имеет значения, как она это делает. Для целого в его отношении с частью
важен только результат её функционирования. И в этом - отличительный принцип
отношения части и целого. Отсюда мы получаем чёткую структурированность части и
целого. Целое как объект состоит из множества своих частей как объектов. Отсюда
получаем принцип адресации объектов, находящихся в отношении части и целого:
Если есть целое, состоящее из множества частей, то множеству частей могут
быть даны их индивидуальные имена т.о., что части, выполняющие различные
функции, обозначаются их общим именем и индивидуализирующим признаком. Например,
в форму могут входить метки типа Label, кнопки типа Button. Но они не могут
входить в виде общих понятий. Они могут входить в объект только как объекты, и
поэтому они должны быть индивидуализированы в виде Labeli, Butteni, где i =
1,2,... Отсюда мы получаем и формы адресации, например:
Form1->Panel2->Label4->Caption =ffff; Эта запись означает, что в Form1
существует объект Panel2, частью которого является метка Label4, которая
обладает свойством Саption, которому приписывается модификация ffff.
Всякая часть целого получает информацию от целого и выполняет в нём функции, в
конечном счете необходимые для целого. Т.о. каждая часть должна быть связана с
целым при посредстве переменных. В то же самое время она, выполняя свои
собственные функции, формирует свои собственные переменные, которые касаются
только и видимы только в ней. Аналогично, часть формирует свои собственные
функции (действия) при выполнении своей частной функции в целом, которые также
относятся только к ней и никого больше не интересуют. Отсюда получаем принцип
видимых и невидимых переменных и функций. Если каждую часть представить в виде
{}, то получим, что вы выражении {j {i}{i}} переменные i внутри скобок видимы
только в них причём, для выведения информации о результатах части необходима
внешняя по отношению к ним переменная j, которая видима внутри частей.
Естественно, что любая система может быть сколь угодно сложной. В любой данный
момент выполняется какая-то одна часть. В этом случае можно говорить о том, что
она находится в фокусе. Это значит, что управление в пределах её функции
передано ей. Выполнив свою функцию, часть возвращает управляющую функцию целому,
которому она принадлежит.
Разумеется, в качестве объектов выступают не
только чувственно-воспринимаемые объекты типа визуальных компонентов, но и
всевозможные абстрактные объекты. Когда мы переходим к ним, мы переходим ко
второй, содержательной стороне построения программы.
23.11.08 г.
Попробуем пожевать
Возвращаемся к игре в кости. Так как русский человек полагает,
что всё знает... Как-то Витя Коновалов, с трудом окончивший школу, говорит мне:
"Что, как дела? Если не будет решаться задача по автоматике, заходи,
помогу". Я в то время учился на четвёртом курсе НПИ. Но это сидит уже в крови.
Так и я, подобно Вите, говорю: "мы пойдём своим путём".
Итак, у нас в игре участвуют два объекта, два игрока: пользователь и
компьютер с тождественно-зеркальными функциями, то есть игроки противостоят друг
другу. И, конечно. в игре должны существовать правила. А так как во всякой игре
с каждой из сторон связывается вектор, направленный на нарушение законов игры в
свою пользу. то должна существовать независимая инстанция в лице судьи, которая
следит за строгим выполнением законов игры. Действия обеих сторон одинаковы,
хотя и противостоят друг другу. Так как эти действия одинаковы, то они также
могут быть переданы независимой силе - Refere, который выполняет все действия
сам. Рефери должен сообщать инофрмацию, связанную с ходом игры, игрокам и
получать данные о решениях игроков. Т.о., действия игроков в принципе сводятся к
ответам "да - нет". И отсюда следует также изменение в игре: речь идет просто о
двух игроках, а не об игроке и компьютере. Итак, рефери должен задавать
вопросы, на которые должен следовать ответ со стороны лица, которому задается
вопрос в виде "да" либо "нет". И рефери действует в соответствии с полученным
ответом. Есть в игре еще один объект, еще одно "действующее лицо" -
игральный кубик. Тогда алгоритм игры может выглядеть следующим образом. Лицом,
управляющим игрой, является рефери. Игра, которая не
начата, может быть только начата.
Игра, которая идет, может быть продолжена или прекращена.
Игра состоит из ходов игроков. Каждый ход игрока реализуется
бросанием кубика, считыванием полученных очков и в зависимости от числа очков
осуществляется передача хода другому игроку с обнулением очков, полученных
игроком в текущей непрерывной серии ходов, либо суммированием очков с очками,
набранными в текущей сессии ходов и ответом игрока, что он либо передает ход
противнику, и тогда набранные им в сессии очки суммируются с очками, уже
набранными игроком, либо же он продолжает бросать кубик.
5. Принцип подражания
Принцип подражания включает в себя два противоположных пункта: переход от
конкретики к обобщению и затем от обобщения к иной конкретике. Другими словами,
на основе конкретики создаются шаблоны, которые применяются к данному виду
объектов.
5.1 Подведение неизвестного под известное
Всё новое, наряду с какими-то известными свойствами, содержит в себе
иррациональную часть, содержащую в себе отсутствующий в нашем опыте принцип.
Познание всякого нового начинается с выявления в нём уже известного и подведения
нового под известное. В результате этого возникает ситуация, при которой новый
объект соотносится с множеством свойств других, известных объектов(рис.1) и это
обычно ведет к формам отождествления нового со старым, которое, однако,
оказывается неудовлетворительным, так как ведет к противоречиям. Когда удаётся выявить в
объекте максимум из того, что в нём соответствует известному нам опыту, остаётся
иррациональный остаток, который, с одной стороны, связан с неизвестными данными,
связанными с отсутствием опыта в их восприятии, и с другой стороны, со способом
взаимодействия, взаимоотношения также и известных частей объекта. Но во всяком
случае, в результате проведенной работы объект уже выделен в чувстве, уже
существует как самостоятельное образование, и теперь уже мы можем действовать с
самим объектом, не прибегая к отождествлению его с тем, чем он не является. И
уже практический опыт оперирования с объектом позволяет наконец сформировать его
знание как знание его, а не его как отражения в нём других объектов.
Это же относится и к выражению (обозначению, формам (знаковой) материализации
объекта.
Попробуем рассмотреть понятие класса.
"Класс — это тип данных, определяемый пользователем. То, что в
C++Builder имеется множество предопределенных классов, не противоречит этому
определению — ведь разработчики C+4-Builder тоже пользователи C++. Понятия
класса, структуры (см. разд. 14.11) и объединения в C++ довольно близки друг к
другу. Поэтому почти все, что будет далее говорится о классах, применимо также к
структурам и объединениям."[2]
Итак, класс - это тип данных. При рассмотрении понятий одни из них
информационно нагружены, другие - нет. В данном случае "данные" - понятие
интуитивно ясное. Это какая-то информация. Дальше -
тип данных. С логической стороны тип - это вид рода. И тут мы
сталкиваемся с первым важным затруднением: под "данными" мы можем понимать
родовое понятие. Но под данными мы можем понимать также и денотаты (элементы
объема) соответствующего понятия. Памятуя, что мы имеем дело, с одной стороны, с
теорией, с другой стороны - с практикой, причём, практика положена, то есть
является целью теории, мы должны придти к выводу, что в конечном счете мы
будем оперировать с объектами, которые будут упорядочиваться посредством общих
понятий, или, другими словами, мы будем иметь дело с нарицательными1и
собственными именами. Мы имеем дело со специфической предметной областью и
нас должно интересовать, как термины употребляются именно в ней. Начнём с того,
относительно чего мы полагаем, что знаем достаточно хорошо. Это понятие
переменной. Математически переменная - величина, которая может изменять своё
значение.
"Переменная является идентификатором, обозначающим
некоторую область в памяти, в которой хранится значение переменной. Это значение
может изменяться во время выполнения приложения."[2] В этом высказывании
мы имеем связки двух сторон, понятие математической переменной и её машинную
материализацию. При этом, хотя целью нашей является
функция машины, мы не можем абстрагироваться от того, как эта функция
реализуется посредством
машины. "Объявление переменной имеет вид:
тип список_идентификаторов_переменных; Список
идентификаторов может состоять из идентификаторов переменных, разделенных
запятыми. Например: int xl, х2; Одновременно с
объявлением некоторые или все переменные могут быть ини- циализированы.
Например: int Xl - Г; х2 = 2; Для инициализации можно
использовать не только константы, но и произвольные выражения, содержащие
объявленные ранее константы и переменные. Например: int xl = 1, х2 = 2 * xl;
Объявление переменных может быть отдельным оператором или делаться внутри таких
операторов, как, например, оператор цикла: for ( int i = 0; i < 10; i + +)"[2].
Итак, то, что касается переменной, то сама по себе переменная - это объект,
свойства которого определяются посредством приписыванию ему каких-то типов.
Например, если это тип int, то этим типом определяется область
целочисленных значений, которые может принимать переменная,
double - десятичные. Значит, типом объекта определяется его объём, то есть
типом объекта определяется, какие объекты являются элементами (копиями) данного
объекта.
Теперь эти вещи нужно обобщить. 1. Типы могут быть
определенные и определяемые. Всякий определенный тип был в свой время
определяем. То есть мы имеем процесс определения, в результате которого
появилось определенное. Естественно, что то, что определено, выступает в
качестве средств, орудий, которые мы применяем на практике. Но нас всегда
интересует, как всё это делается, какая логика заложена во всё это. Ведь если
нам известна логика, то мы и сами сможем кое-что сделать.
Подойдём к вопросу со стороны логики. Пусть есть класс растений, в котором мы
выделим траву, кустарники, деревья, а среди деревьев выделим дубы, березы,
тополя. Мы уже поняли, что задание типа переменной означает определение объёма
понятия, под которое в машине должна выделяться соответствующая память. Поэтому
при определении соответствующих переменных мы могли бы записать: растение х = |
собственное имя элемента объёма понятия растение |, дерево=у; береза=z; где
области определения переменных х,y,z будут, конечно, различаться. Здесь же
следует сразу же обратить внимание на то, что мы имеем дело с системой, то
недостаточно записать просто береза = z; , поскольку из точки, в которой мы
находимся, мы не увидим эту переменную. Отсюда возникает проблема видимости; для
того, чтобы увидеть переменную, нам нужно знать путь из точки, в которой мы
находимся, в точку, в которой находится переменная. А отсюда уже просматривается
и программный алгоритм. Именно, пусть мы имеем сколь угодно сложную
иерархическую систему, представленную деревом. Тогда выполнение любой программы
будет состоять в том, что вершина дерева будет представлена основной программой.
Из вершины дерева выходит множество ветвей, который заканчиваются узлами, из
которых, в свою очередь, выходят ветви и т.д. Реализация программы может быть
сколь угодно сложной, но работа её подчиняется общему правилу: все нижележащие
относительно данного узла дерева узлы являются подпрограммами. Подпрограмма
выполнена - и происходит возврат управления в узел, которым она была
активизирована. Т.о. получается, мы можем сколь угодно долго идти из
подпрограммы одного уровня в подпрограмму следующего уровня, но выполнение любой
подпрограммы даёт автоматический "отскок" на программу более высокого уровня. А
отсюда получаем, что, если исходить из такой схемы построения программы, то для
того, чтобы перейти на другую ветвь дерева, мы должны возвратиться в узел, общий
для обеих ветвей. (Здесь у нас может возникнуть вопрос о том, что,
возможно, в данной подпрограмме понадобятся переменные, полученные в других
подпрограммах, и подпрограмма должна иметь возможность к ним обращаться.2
) В разделе 3 речь шла об интерпретации дерева не только как
отношения рода-вида, а как части-целого. Сравнительно с родовидовыми отношениями
отношения части-целого характеризуются наглядностью, и в них особенно наглядно
то, что адресация должна идти из точки, в которой мы находимся, в точки
нижележащих узлов. Если мы находимся в узле "растение", то мы не можем
непосредственно перейти к березе. Мы должны записать последовательность
растение->дерево->береза. Имея дело с автомобилем, мы не можем непосредственно
перейти к поплавковой камере, но должны написать:
Автомобиль.двигатель.карбюратор.поплавковая камера = х.
В естественном языке мы наблюдаем двойственность в обозначении индивида и
вида. Мы говорим, указывая на березу: береза. При этом мы можем иметь ввиду
понятие, а можем иметь ввиду данное дерево. чтобы иметь возможность различать
смысл, в котором мы употребляем термин, мы должны будем термину придать
дополнительные признакию. Например, мы можем обозначить Тбереза как понятие,
берёзаi, где i=1,2,.. - как объект данного рода. Но в результате этого мы
получим формально два разных имени, и тогда мы должны образовать суждение:
береза1 есть Тбереза, или создать указатель Тбереза *береза1 или сделать это еще
как-=нибудь иначе, что данный объект является элементом какого-то класса
объектов. Например, записав: Лаура есть Тбереза, мы тем самым определили, что
Лаура суть береза. Мы тем самым определили тип (вид) объекта.
Значит, если бы мы захотели ввести тип3
объекта, то во всяком случае мы должны иметь денонат. А уже имея дело с
объектом, мы можем говорить о его всевозможных свойствах и его поведении
(методах), о том, что он делает.
Примечания 1
Нарицательные имена — имена существительные, обозначающие название (общее имя)
целого класса предметов и явлений, обладающих определённым общим набором
признаков, и называющие предметы или явления по их принадлежности к такому
классу.(Википедия)
назад
2 "При
решении вопросов видимости важнейшее значение имеет понятие блока. Блок — это
фрагмент кода, ограниченный фигурными скобками "{}". Переменные, объявленные вне
какого-то блока, являются глобальными и имеют областью видимости файл. Если
какая-то переменная объявлена внутри блока, то ее область видимости — блок. Т.е.
это локальная переменная, которую можно использовать только от момента ее
объявления до первой встретившейся в коде закрывающейся фигурной скобки "}".
Если имеются вложенные блоки, то переменная видна и в этих вложенных блоках.
Если в каком-то блоке объявлена переменная с тем же именем, какое имеет
глобальная переменная или переменная, объявленная во внешнем блоке, то это
внутреннее объявление делает невидимой одноименную внешнюю переменную.
Например: int i = 1, k = 4 // объявление глобальных
переменных { int 1 = 5 , j =
2; // объявление переменных внешнего блока ... // видны
переменные j , k // и переменная i этого блока
( int i = 7; // объявление переменной i внутреннего
блока ... // видны переменные j , k
// и переменная i внутренняя }
... // видны переменные j , k // и переменная i
внешнего блока )
Локальная
переменная не только видима в пределах блока, в котором она объявлена. Ее время
жизни тоже определяется временем выполнения блока. Переменная создается в момент
входа в блок и разрушается в тот момент, когда управление выходит за пределы
блока. Таким образом, подобная переменная не может сохранять какие-то значения в
промежутках между выполнением операторов блока. В приведенном выше примере
переменная i во внутреннем блоке будет создаваться
каждый раз, когда управление передается в этот блок, ей каждый раз будет
присваиваться значение 7 и она каждый раз будет разрушаться при выходе из
блока......." Каждая переменная характеризуется некоторым классом памяти,
который определяет ее время жизни — период, в течение которого эта переменная
существует в памяти. Одни переменные существуют недолго, другие — неоднократно
создаются и уничтожаются, третьи — существуют на протяжении всего времени
выполнения программы.
В C+4-Builder имеется четыре спецификации класса памяти: auto,
register, extern и static. Спецификация класса памяти идентификатора определяет
его класс памяти, область действия и пространство имен.
Областью действия (областью видимости) идентификатора называется
область программы, в которой на данную переменную (как, впрочем, и на любой
идентификатор — константу, функцию и т.п.) можно сослаться. На некоторые
переменные можно сослаться в любом месте программы, тогда как на другие — только
в определенных ее частях.
Класс памяти определяется, в частности, местом объявления переменной.
Локальные переменные объявляются внутри некоторого блока или функции. Эти
переменные видны только в пределах того блока, в котором они объявлены. Блоком
называется фрагмент кода, ограниченный фигурными скобками "{ }". Глобальные
переменные объявляются вне какого-либо блока или функции.
Спецификации класса памяти могут быть разбиты на два класса:
автоматический класс памяти с локальным временем жизни и статический класс
памяти с глобальным временем жизни. Ключевые слова auto и register используются
для объявления переменных с локальным временем жизни. Эти спецификации применимы
только к локальным переменным. Локальные переменные создаются при входе в блок,
в котором они объявлены, существуют лишь во время активности блока и исчезают
при выходе из блока. Ключевые слова extern и static используются,
чтобы объявить идентификаторы переменных как идентификаторы статического класса
памяти с глобальным временем жизни. Такие переменные существуют с момента начала
выполнения программы. Для таких переменных память выделяется и инициализируется
сразу после начала выполнения программы. Существует два типа
переменных статического класса памяти: глобальные переменные и локальные
переменные, объявленные спецификацией класса памяти static. Глобальные
переменные по умолчанию относятся к классу памяти extern.
Глобальные переменные создаются путем размещения их объявлений вне
описания какой-либо функции и сохраняют свои значения в течение всего времени
выполнения программы. На глобальные переменные может ссылаться любая функция,
которая расположена после их объявления или описания в файле. Локальные
переменные, объявленные с ключевым словом static, известны только в том блоке, в
котором они определены. Но в отличие от автоматических переменных, локальные
переменные static сохраняют свои значения в течение всего времени выполнения
программы. При каждом следующем обращении к это- му блоку локальные переменные
содержат те значения, которые они имели при предыдущем обращении.
Вернемся к уже рассмотренному выше примеру, но укажем для переменной
i статический класс:
(
static int i = 1;
Инициализация переменной i произойдет только один раз за время
выполнения программы. При первом обращении к этому блоку значение переменной i
будет равно 1. К концу выполнения блока ее значение станет равно 2. При
следующем обращении к блоку это значение сохранится и при окончании повторного
вы- полнения блока i будет равно 3. Таким образом, статическая переменная
способна хранить информацию между обращениями к блоку и, следовательно, может
использоваться, например, как счетчик числа обращений.
Все числовые переменные статического класса памяти принимают нулевые
на- чальные значения, если программист явно не указал другие начальные значения.
Статические переменные — указатели, тоже имеют нулевые начальные
значения.
Спецификации класса памяти extern используются в программах с
несколькими файлами. Пусть, например, в модуле Unitl в файле Unitl.cpp или
Unitl.h (это безразлично) объявлена глобальная переменная
int a = 5;
Тогда, если в другом модуле Unit2 в файле Unit2.cpp или Unit2.h
объявлена- глобальная переменная
extern int а; то компилятор понимает, что речь идет об одной и той же
переменной. И оба моду- ля могут с ней работать. Для этого даже нет
необходимости связывать эти модули директивой #include (см. разд. 13.2.1),
включающей в модуль Unitl заголовочный файл второго модуля:[2]назад
3
"Пользователь может вводить в программу свои собственные типы. Объявления типов
могут делаться в различных местах кода. Место объявления влияет на область
видимости или область действия так же, как и в случае объявления переменных (см.
разд. 13.6).
Синтаксис объявления типа:
typedef определение_типа идентификатор;
Здесь идентификатор — это вводимое пользователем имя нового типа, а
определение_типа — описание этого типа. Например, оператор typedef double
Ar[10]; объявляет тип пользователя с именем Аг как массив из 10 действительных
чисел.
В дальнейшем на этот тип можно ссылаться при объявлении
переменных. Например: Аг А = { 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 ,
9 , 1 0 } ; "[2] назад
26.11.08 г.
5.2 Субъект-объект (Субъективный объект)
О последовательности и скачках. В процессе познания присутствуют
как бы иррациональные скачки, очевидно, формальный процесс познания далёк от
окончания, но бессознательному он становится ясен, и тогда осуществляется
переход к следующей области. Всегда присутствует этот "иррациональный" скачок из
известного в новое неизвестное.
Вся сложность в процессе любого
познания состоит в обеспечении его системности, или последовательности. Мы
должны закрепиться на какой-то точке, от которой протягиваем нити к другим
точками т.о., чтобы мы всегда имели возможность возвратиться в исходную точку.
Иначе говоря, недопустим никакой обрыв нити. Переход из точки в точку можно
считать осуществленным только тогда, когда нами обеспечен обратный переход в
исходную точку. Это является показателем включения новый точки в систему знания.
Объектно-ориентированное программирование
(сокращенно ООП) — это в наше время совершенно естественный подход к построению
сложных (и не очень сложных) программ и систем. Когда вы открываете любую
программу Windows, вы видите окно с множеством кнопок, разделов меню, окон
редактирования, списков и т.п. Все это объекты. Причем сами по себе они ничего
не делают. Они ждут каких-то событий — нажатия пользователем клавиш или кнопок
мыши, перемещения курсора и т.д. Когда происходит подобное событие, объект
получает сообщение об этом и как-то на него реагирует: выполняет некоторые
вычисления, разворачивает список, заносит символ в окно редактирования. Вот
такая программа Windows и есть объектно-ориентированная программа (для краткости
в дальнейшем на протяжении этой книги мы будем называть прикладные программы
приложениями).[2]
Если мы посмотрим на определение объекта,
данное во
[2], то увидим внешнее определение объекта, то
есть объекта как объекта, как такой внешней вещи, которая видится и, в
соответствии с её видением описываются её свойства и её действия. В результате
этого мы входим в ситуацию, когда за деревьями перестаёт видится лес. Лес - это
целостность, это - субъективность. То есть это - не набор каких-то свойств,
методов, средств, но это - действующая субъективность. Только субъективность
вносит целостность в многообразие. Всё то, о чем идёт речь во [2], всё это
должно стать субъективным содержанием программиста. А субъективность - это то,
что действует. Значит, к объекту мы должны относиться не только как к внешней
мертвой вещи, но как к субъективности, которая действует, с одной стороны, и
которая создает самое себя - с другой. И, значит, мы должны рассматривать
объекты не только с их объективной, но и с их субъективной стороны, подводя
объективное под субъективное, делая его частью субъективной жизни и субъективной
активности. Имея дело с понятиями и представляющими их в чувственной сфере
образами мы должны рассматривать их как то, что действует. Психологически это
означает отождествление я субъекта с соответствующими понятиями и
превращение понятий из субстантивированных
вещей в действующие, из существительных в глаголы.
Итак, на данном
этапе такие объекты, (визуальные) компоненты мы рассматриваем как
субъекты. Когда мы имеем дело с субъектом, мы обращаем внимание на то, что
субъект способен к восприятию, переработке информации и действию.
Из
сказанного следует понятие межсубъектных отношений. Мы признаём, что наряду с
нами существуют другие субъекты, подобные нам. При этом каждый из субъектов есть
субъект-объект. То есть не мы одни на свете живые. А существуют еще кнопки,
меню, списки и т.д., которые способны как к восприятию информации, так и к
действиям. Т.о. мы получаем субъективную (субъект-объектную) систему, состоящую
из множества субъектов, и возникает вопрос о законах, которым подчиняется эта
система, причем, эти законы могут быть как общими для всех субъект-объектных
элементов системы, так и частными, характеризующими виды субъектов.
Что нам дает такой подход? В отличие от мёртвого объекта субъект - это
открытая система, которая способна втягивать в себя любые объективные элементы,
субъективируя их, превращая их в часть себя. В этом смысле изначально, в своей
основе субъект обладает единственным свойством - способностью делать своими
внешние содержания, тогда как сам по себе субъект - это открытая система,
субъективная способность, не обладающая в себе никаким объективным содержанием,
но способная к существованию только на основе усваиваемого ею объективного
материала.
Так как всему этому противостоит пользователь, то мы
получаем такую ситуацию, что в исходной ситуации пользователю противостоят
объекты, и целью пользователя является их субъективация, то есть превращение их
в часть себя.
Но здесь присутствует и другая важнейшая сторона.
Обратите внимание на то, что человек относится к природе как к тому, что
обладает разумом, то есть он относится к природе как к такому же по сути
субъективному существу, как он сам. Он ищет в природе разум и находит его. В
любом объекте он ищет разумные вещи. И уж тем более человек относится к тому,
что создал он сам, как к разумному, и в том числе и к системам понятий и
образом, представленных в текстах, программах и т.д. За всякой целостностью
стоит какой-то разум. Его нужно уметь увидеть. Значит, имея дело с объектами, мы
должны искать тот разум, который их создал и те смыслы, которые он вложил в
объекты. Поэтому мы имеем два как бы противоположных полюса: на одной стороне
пользователь со своим разумом, на другой стороне - разум, стоящий за объектами,
созданными им. Т.о., в объектах является разум. И чтобы понять смысл и значение
объектов, нужно понять цели разума, создавшего их, и средства, которые
использовал разум при построении своих объектов.
Проведем
такой опыт: Откроем новое приложение и перенесем на форму кнопку. Дважды нажмём
на неё и в конструкторе кнопки запишем Form1->Caption = "форма";
Button1->Caption = "пуск"; а в конструкторе формы - Form1->Caption = "форма2";
Button1->Caption = "пуск1";. Мы с вами помним, что имеем дело с двумя
субъективностями - формой и кнопкой. Откомпилируем и запустим программу. Form1
превратится в форма2, а на кнопке появится надпись пуск1. Теперь нажмём на
кнопку. "форма2" превратится в "форма", а надпись на кнопке превратится в
"пуск". Остановим программу: восстановятся Form1 и Button1. Button1. В то же
самое время, если мы произведем соответствующие изменения в Инспекторе объектов,
то надписи останутся неизменными. Значит, при запуске программы выполняются
свойства, которые записаны в конструкторе, причем, при открытии форма выполняет
команды, записанные в ней.
1
Приложение, построенное по принципам объектной ориентации — это не
последовательность каких-то операторов, не некий жесткий алгоритм.
Объектно-ориентрованная программа — это совокупность объектов и способов их
взаимодействия. Отдельным (и главным) объектом при таком подходе во многих
случаях можно считать пользователя программы. Он же служит и основным, но не
единственным, источником событий, управляющих приложением. Попробуем разобраться
с основным понятием ООП — объектом. Для начала можно определить объект как некую
совокупность данных и способов работы с ними. Данные можно рассматривать как
поля записи. Это характеристики объекта. Пользователь и объекты программы
должны, конечно, иметь возможность читать эти данные объекта, как-то их
обрабатывать и записывать в объект новые значения. Здесь важнейшее значение
имеют принципы инкапсуляции и скрытия данных. Принцип скрытия данных заключается
в том, что внешним объектам и пользователю прямой доступ к данным, как правило,
запрещен. Делается это из двух соображений. Во-первых, для надежного
функционирования объекта надо поддерживать целостность и непротиворечивость его
данных. Если не позаботиться об этом, то внешний объект или пользователь могут
занести в объект такие неверные данные, что он начнет функционировать с
ошибками. Во-вторых, необходимо изолировать внешние объекты от особенностей
внутренней реализации данных. Для внешних потребителей данных должен быть
доступен только пользовательский интерфейс — описание того, какие имеются данные
и функции и как их использовать. А внутренняя реализация — это дело разработчика
объекта. При таком подходе разработчик может в любой момент модернизировать
объект, изменить структуру хранения и форму представления данных, но, если при
этом не затронут интерфейс, внешний потребитель этого даже не за- метит. И,
значит, во внешней программе и в поведении пользователя ничего не придется
менять. Чтобы выдержать принцип скрытия данных, в объекте обычно определяются
процедуры и функции, обеспечивающие все необходимые операции с данными: их
чтение, преобразование, запись. Эти функции и процедуры называются методами и
через них происходит общение с данными объекта. Совокупность данных и методов их
чтения и записи называется свойством. Со свойствами вы будете иметь дело на
протяжении всей этой книги. Свойства можно устанавливать в процессе
проектирования, их можно изменять программно во время выполнения вашей
прикладной программы. Причем внешне это все выглядит так, как будто объект имеет
какие-то данные, например, целые числа, которые можно прочитать, использовать в
каких-то вычислениях, заложить в объект но- вые значения данных. В процессе
проектирования вашего приложения с помощью C++Builder вы можете видеть значения
некоторых из этих данных в окне Инспектора Объектов, можете изменять эти
значения. В действительности все обстоит иначе. Все общение с данными происходит
через методы их чтения и записи. Это происходит и в процессе проектирования,
когда среда C++Builder запускает в нужный момент эти методы, и в процессе
выполнения приложения, поскольку компилятор C++Builder незримо для разработчика
вставляет в нужных местах программы вызовы этих методов. Помимо методов,
работающих с отдельными данными, в объекте имеются методы, работающие со всей их
совокупностью, меняющие их структуру. Таким образом, объект является
совокупностью свойств и методов. Но это пока нельзя считать законченным
определением объекта, поскольку прежде, чем дать полное определение, надо еще
рассмотреть взаимодействие объектов друг с другом. Средой взаимодействия
объектов (как бы силовым полем, в котором существу- ют объекты) являются
сообщения, генерируемые в результате различных событий. События наступают,
прежде всего, вследствие действий пользователя — перемещения курсора мыши,
нажатия кнопок мыши или клавиш клавиатуры. Но события могут наступать и в
результате работы самих объектов. В каждом объекте определено множество событий,
на которые он может реагировать. В конкретных экземплярах объекта могут быть
определены обработчики каких-то из этих событий, которые и определяют реакцию
данного экземпляра объекта. К написанию этих обработчиков, часто весьма простых,
и сводится, как будет видно далее, основное программирование при разработке
графического интерфейса пользователя с помощью C++Builder. Теперь можно
окончательно определить объект как совокупность свойств и методов, а также
событий, на которые он может реагировать. Условно это изображено на рис. 1.1.
Внешнее управление объектом осуществляется через обработчики событий. Эти
обработчики обращаются к методам и свойствам объекта. Начальные значения данных
объекта могут задаваться также в процессе проектирования установкой различных
свойств. В результате выполнения методов объекта могут генерироваться новые
события, воспринимаемые другими объектами программы или пользователем.
назад
5.3 Формализм
Рефлекс, пока он формируется, в нём доминирует ОИР и все действия,
связанные с формированием рефлекса, носят содержательный характер. Но когда
рефлекс сформирован, когда он превратился в стереотип, тогда он представляет
собой формализм в чистом виде. В процессе познания мы имеем дело с этими двумя
сторонами: содержательной и формальной. В конечном счете форма должна быть
приведена к содержанию, и содержание должно иметь соответствующую ему форму.
Иначе говоря, как представляется, существует стремление к достижению
одно-однозначного отношения между содержанием и формой, в живой жизни всегда
нарушаемое логикой привходящих содержаний и логикой развития форм.
Формализм подчиняется формальной логике, и следует
посмотреть приёмы, которые связаны с формализмами.
Займёмся своего рода игрой. Пусть нам дано объявление класса.
Заголовочный модуль: #ifndef UnitlH
#define UnitlH
//--------------
#include #include #include #include //----------------
class TForml : public TForm
{
published: // IDE-managed Components
TLabel *Labell;
TButton *Buttonl;
void fastcall ButtonlClick(TObject *Sender);
private: // User declarations
// Функция Fl и переменная Ch6 доступны только в данном модуле
void fastcall Fl(char Ch) ;
char Ch6;
public: // User declarations
__fastcall TForml(TComponent* Owner);
// Переменная Chi и функция F2 доступны для объектов
// любых классов и для других модулей, но со ссылкой
// на объект
char Chi;
void __fastcall F2 (char Ch) ;
};
// ---------------------------------------------------------
extern PACKAGE TForml *Forml;
// Глобальная переменная Ch2 и функция F3 доступны в пределах
// данного модуля; переменная Ch2 доступна в других модулях,
// если определена там со спецификацией extern;
// функция F3 доступна в других модулях, если там содержится
// ее прототип
char Ch2;
void F3 (char Ch) ;
#endif
Мы занимаемся не содержанием, а формализмами, и занимаемся
овладением формализмами. Поэтому мы берем, например, выражение class
TForml : public TForm {}; выделяем в нём форму: class T...l : public
T... {}; и подставляем в форму всё объекты, которые обладают формальными
признаками Т и 1. И тогда мы получаем множество объектов: classTButton1 : public
TLabel ; class TLabel1 : public TLabel {}; class TBrush1 : public TBrush
{}; при этом, конечно, формализм должен иметь для нас смысл, мы должны знать что
в первой части шаблона мы подставляем имя класса, во второй - его родителя. Если
родителя нет, то вторая часть отсутствует.
Строим следующий шаблон:
published: // IDE-managed Components
TLabel *Labell;
TButton *Buttonl;
void _fastcall ButtonlClick(TObject *Sender); Из
содержания нужно знать, что в published вносятся данные о компонентах и
событиях, связанных с ними. Шаблон компонента содержит указатель объекта
на тип: Т... *...1; шаблон события имеет вид: void _fastcall
(объект) (вид воздействия на него)(TObject *Sender); Из
содержания нужно знать, что в published вносятся данные о компонентах и
событиях, связанных с ними. Шаблон компонента содержит указатель объекта
на тип: Т... *...1; шаблон события имеет вид: void _fastcall
(объект) (вид воздействия на него)(TObject *Sender);
А
если опираться не на выявленные шаблоны, а на рефлексы, что в этом случае мы
получаем? Какого рода автоматизм, или умозаключение в этом случае имеет место?
Если
TButton *Buttonl; void _fastcall
ButtonlClick(TObject *Sender); , то всякий объект, являющийся указателем
на тип, может быть подставлен на место Button - например, Label, Edit и т.д.
5.4 Формирование навыка
Важным
препятствием в познавательной деятельности является отсутствие навыков действия.
Обычно есть знание чего-то, есть знание "как", но отсутствие навыков
препятствует осуществлению действия, причём, существует стойкое сопротивление
осуществлению действия. Как правило, приходится приложить усилия к тому, чтобы
заставить себя делать то, что нужно, поскольку при этом присутствует ощущение
ломки существующих стереотипов. Возможно, для облегчения этого процесса также
следует идти к неизвестному через известное. Тем препятствием, с которым
сталкиваешься при этом, является отсутствие кодов тех результатов, которые мы
должны получить при выполнении действия. Их действительно еще нет. Ведь их нужно
сформировать. Код - это результат, который формируется по обратной связи: мы
сделали и получили результат и восприняли его. После этого отношения
переворачиваются, и то, что мы восприняли, становится перед действием.
Воспринятое становится той целью, которую мы должны реализовать. Ориентировочная
реакция нам даёт: если я сделаю то-то по отношению к тому-то, то получу такой-то
результат. Когда результат известен, то человек говорит: для того, чтобы
получить то-то, я должен сделать то-то по отношению к тому-то. Первоначально
новое действие затормаживается в силу его неизвестности а также неизвестности
его последствий; ведь при этом нужно отрешиться от уже существующих кодов и
исходить из возможных действий по отношению к существующему материалу, а против
этого восстаёт врожденный инстинкт опасности всего нового как того, что может
грозить неприятностями. И поэтому существует тенденция исключения новых
действий, поскольку они могут быть не только заряжены опасными
последствиями, но они также еще и энергоёмки. Поэтому приходится прилагать
усилия для преодоления возникающих торможений. И следующий момент, когда найдены
удачные схемы действий, когда уже знаешь, как действовать, этого также
оказывается недостаточно; необходимо их повторение с целью формирования
стереотипов действия с тем, чтобы минимизировать ориентировочную реакцию. Ведь
та основная деятельность, которую выполняет человек, имеет в своей основе
ориентировочную деятельность, а для реализации её целей нужны не отвлекающие от
её реализации средства, а они доставляются только стереотипами. Движение вперед
заключается в том, чтобы новые знания преобразовывать в умения как средство
получения последующего знания.
* * *
В этой точке мы снова совершим скачок, опустив
дальнейшее как вещь, способ познания которой задан. Всякое событие есть
воздействие пользователя, и нас интересуют реакции на события. Реакции на
события оформляются в форме методов. Нас будут интересовать общие принципы,
относящиеся к применению существующих программ методов. Но прежде, чем
заниматься философствованием в этой области, обратимся к практике.
