Письмо 01 - Страница 05

Можно написать набор макроопределений, который бы позволил статически и динамически создавать фигуры и вектора-переключатели, а также вызывать подпрограммы. Это задача достаточно тривиальная, например, можно посмотреть те макроопределения, которые фирма Borland (теперь Inprise) предложила в TASM 3.0.

Гораздо важнее другое, теперь при добавлении новой фигуры не потребуется изменять существующие исходные тексты, достаточно просто добавить это описание к существующей программе. Мало того, достаточно легко создать run-time модуль, который позволит создавать и подключать новые фигуры прямо во время работы. Однако есть определённое неудобство в том описании структур фигур, которое приведено выше. Во время исполнения неизвестно какой фигуре принадлежит та или иная структура. Пока есть возможность работать с фигурами статически, особых проблем не возникает, но при динамичном создании структур и взаимодействии с ними, проблемы возникнут непременно. Самый простой способ решения этой проблемы состоит в том, чтобы включить описатель типа структуры непосредственно в саму структуру.

Например :

Struc tLine     kind dd  ?  ; тип фигуры     x dd ? ; x - координата якорной точки     y dd ? ; y - координата якорной точки     x1 dd ? ; x – координата конца линии     y dd ? ; y – координата конца линии ends tLine

В поле «kind» можно поместить уникальный идентификатор той фигуры, к которой относится данная структура данных. Но обычно поступают проще, помещая в это поле ссылку на вектор-переключатель фигуры. В этом случае вызов подпрограмм, реализующих действия, для любой фигуры превратиться в следующую последовательность действий:

; пусть eax содержит ссылку на структуру, тогда     push eax ; здесь передаём в стек остальные параметры ...     mov  eax,[eax] ; адрес вектора-переключателя ; поместим в eax     call [eax + Action4] ; вызовем нужную подпрограмму ; (Action4 = Action * 4)

Другое важное отличие второго решения состоит в том, что в подпрограммы, реализующие некоторые действия, теперь можно передавать типизированные ссылки на конкретные структуры вместо произвольных ссылок. В этом случае компилятор с языка высокого уровня может взять на себя проверку правильности типов данных. Мало того, ссылку можно передавать неявно, избегая, тем самым, возможных ошибок программиста.

Вектора-переключатели обычно называют виртуальными таблицами, но в данном изложении мне казалось, что стоит повременить с переименованием, дабы как можно дольше сохранять связь с операторами языков высокого уровня таких, как switch-case (в C) или case (в Pascal). Сохранение этой связи преследовало вполне конкретную цель: показать связь между объектной технологией и технологией структурного программирования. Но теперь имеет смысл перейти к общепринятому названию векторов-переключателей – виртуальные таблицы. Таким образом, виртуальные таблицы, связывающие воедино структуры данных и код, взаимодействующий с ними, являются естественным решением при переходе от структурного программирования к объектной технологии. Конечно, виртуальные таблицы - не единственное и даже не лучшее решение, и об этом пойдёт речь в последующих письмах, но на сегодня это решение является весьма распространённым.

Подпрограммы, реализующие некоторые действия, обычно называют методами. Структура данных, связанная с методами, представляет собой объект, а описание структуры и методов обычно называют классом. Таким образом, объект является экземпляром класса. Методы класса, видимые для внешнего программного обеспечения, составляют интерфейс класса. Но, следует отметить, что интерфейс класса не всегда соответствует методам, как подпрограммам. Способ реализации интерфейса может определяться объектной средой.

Сейчас хотелось бы отметить, что мы вплотную подошли к возможности реализации объектной технологии. Фактически осталось только ввести поддержку полиморфизма и наследования, что сегодня, как правило, реализуется в рамках компиляторов. Введение поддержки этих парадигм не вызывает существенных сложностей. Однако наиболее важно понимать другое, то, что объектная технология, являясь прямым продолжением технологии структурной разработки программ, открыла новые принципиально иные подходы к проектированию и разработке сложного программного обеспечения. К сожалению, эти подходы пока очень редко применяются в практике и не отражены в литературе.