Соглашения и руководящие принципы.
Статические методы против виртуальных методов.
Это весьма непростой и спорный вопрос. В "чистых" язы-
ках, использующих подход OOP, статические методы не существу-
ют; все методы являются виртуальными. И сторонник "чистого"
подхода OOP мог бы сказать, что все методы в нашей иерархии
объектов должны быть виртуальными именно по той причине, что
виртуальные методы стоят на первом месте. Такой аргумент мож-
но было бы признать справедливым, но еще больше истины в том,
что делать все методы только виртуальными просто непрактично
- по крайней мере, тогда, когда Вы программируете на Turbo
Pascal.
На наш взгляд, имеются два убедительных довода в пользу
того, чтобы везде, где это только возможно, использовать ста-
тические методы. Во-первых, интеллектуальный компоновщик
Turbo Pascal не может отменять неиспользуемые виртуальные ме-
тоды, а только неиспользуемые статические методы; простой акт
ввода объекта данного типа приводит к тому, что в программу
должны быть скомпонованы все виртуальные методы этого объек-
та. И во-вторых, чем больше виртуальных методов имеет объект,
тем обширнее его таблица виртуальных методов VMT: объект,
имеющий 100 виртуальных методов, использовал бы более 400
байт пространства в сегменте данных. В системе Object
Professional нет ни одного объекта, который бы имел так много
виртуальных методов, но если бы все методы были виртуальными,
в ней бы имелся не один такой объект.
Полагая, что из практических соображений невозможно во
всех случаях применять только одни виртуальные методы, мы
стоим на тех позициях, что целесообразно создавать виртуаль-
ные методы только в следующих трех случаях:
а) если мы знаем, что он должен быть отменен объек-
том-потомком,
б) если метод предназначен для того, чтобы быть отменен-
ным, и для этой цели и существует,
в) если в самой природе метода заложена возможность то-
го, что желательно его отменить в объекте-потомке.
Указатели процедур против производных типов.
Еще один концептуально спорный вопрос. Рассмотрим слу-
чай, когда для некоторого объекта необходимо обеспечить
средство, позволяющее программисту передавать такую информа-
цию для объекта, которая не всегда бывает известна на момент
компилирования. Наглядным примером такого объекта является
"PickList" ("Список_Подбора") в модуле OPPICK: он должен
обеспечить средство, которое предоставит Вам возможность "со-
общить" ему, какие элементы имеются в списке подбора.
Сторонник "чистого" метода мог бы сказать, что для реше-
ния этой проблемы следует обеспечить фиктивный виртуальный
метод, который, как предполагается, будет возвращать необхо-
димую информацию, и пусть потом программист создает производ-
ный тип, который отменяет этот метод. Но такой подход порож-
дает две проблемы. Первая заключается в том, что было бы
досадно, если бы КАЖДЫЙ раз, когда возникает потребность ис-
пользовать, например, объект PickList, пришлось создавать
производный тип, особенно в том случае, если все, что Вам
действительно требуется - это написать функцию для восстанов-
ления строки на основе номера элемента. Вторая проблема сос-
тоит в том, что при этом в большинстве случаев исключается
возможность использования одного и того же объекта PickList
для отображения на экране различных списков.
Мы предпочитаем принять компромиссное решение. В подоб-
ных случаях действительно имеются виртуальные методы, которые
Вы можете отменить, если захотите. Но помимо этого существуют
такие средства, которые с помощью указателя процедуры задают
ту подпрограмму, написанную пользователем, которая нужна для
выполнения операции. Реализация виртуального метода по умол-
чанию просто использует этот указатель процедуры, чтобы выз-
вать Вашу подпрограмму.
Конструкторы и деструкторы.
В системе Object Professional в соответствии с соглаше-
ниями фирмы Borland принято для конструкторов использовать
имя "Init" ("Начальный"), а для деструкторов - имя "Done"
("Законченный"). Большинство объектов также имеет конструктор
с именем "Load" ("Загрузка"), который используется для заг-
рузки объекта из потока (еще больше на потоках через момент
?) - в соответствии с другим соглашением фирмы Borland.
Для обеспечения унификации каждый объект в иерархии име-
ет деструктор с именем Done, даже если он и не нужен, и эти
деструкторы никогда не принимают никаких параметров. Что ка-
сается конструкторов, однако, то здесь существуют некоторые
варианты.
Конструктор Init всегда принимает столько параметров,
сколько возможно. Если в определенных обстоятельствах жела-
тельно передать больше параметров, существует второй конс-
труктор с именем "InitCustom" ("Начальная_Настройка"), кото-
рый их принимает (дополнительно к параметрам, которые
переданы ok
$u
Текущая страница: 1
|
