Статические методы против виртуальных методов

Это весьма непростой и спорный вопрос. В "чистых" язы-

ках, использующих подход 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" ("Начальная_Настройка"), кото-

рый их принимает (дополнительно к параметрам, которые

переданы конструктору Init). В объекте, имеющем конструктор

InitCustom

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать