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

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

ках, использующих подход OOP, статические методы не существу-

ют; все методы являются виртуальными. И сторонник "чистого"

подхода OOP мог бы сказать, что все методы в нашей иерархии

объектов должны быть виртуальными именно по той причине, что

виртуальные методы стоят на первом месте. Такой аргумент мож-

но было бы признать справедливым, но еще больше истины в том,

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

- по крайней мере, тогда, когда Вы программируете на Turbo

Pascal.

На наш взгляд, имеются два убедительных довода в пользу

того, чтобы везде, где это только возможно, использовать ста-

тические методы. Во-первых, интеллектуальный компоновщик

Turbo Pascal не может отменять неиспользуемые виртуальные ме-

тоды, а только неиспользуемые статические методы; простой акт

ввода объекта данного типа приводит к тому, что в программу

должны быть скомпонованы все виртуальные методы этого объек-

та. И во-вторых, чем больше виртуальных методов имеет объект,

тем обширнее его таблица виртуальных методов VMT: объект,

имеющий 100 виртуальных методов, использовал бы более 400

байт пространства в сегменте данных. В системе Object

Professional нет ни одного объекта, который бы имел так много

виртуальных методов, но если бы все методы были виртуальными,

в ней бы имелся не один такой объект.

Полагая, что из практических соображений невозможно во

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

стоим на тех позициях, что целесообразно создавать виртуаль-

ные методы только в следующих трех случаях:

а) если мы знаем, что он должен быть отменен объек-

том-потомком,

б) если метод предназначен для того, чтобы быть отменен-

ным, и для этой цели и существует,

в) если в самой природе метода заложена возможность то-

го, что желательно его отменить в объекте-потомке.

Указатели процедур против производных типов.

Еще один концептуально спорный вопрос. Рассмотрим слу-

чай, когда для некоторого объекта необходимо обеспечить

средство, позволяющее программисту передавать такую информа-

цию для объекта, которая не всегда бывает известна на момент

компилирования. Наглядным примером такого объекта является

"PickList" ("Список_Подбора") в модуле OPPICK: он должен

обеспечить средство, которое предоставит Вам возможность "со-

общить" ему, какие элементы имеются в списке подбора.

Сторонник "чистого" метода мог бы сказать, что для реше-

ния этой проблемы следует обеспечить фиктивный виртуальный

метод, который, как предполагается, будет возвращать необхо-

димую информацию, и пусть потом программист создает производ-

ный тип, который отменяет этот метод. Но такой подход порож-

дает две проблемы. Первая заключается в том, что было бы

досадно, если бы КАЖДЫЙ раз, когда возникает потребность ис-

пользовать, например, объект PickList, пришлось создавать

производный тип, особенно в том случае, если все, что Вам

действительно требуется - это написать функцию для восстанов-

ления строки на основе номера элемента. Вторая проблема сос-

тоит в том, что при этом в большинстве случаев исключается

возможность использования одного и того же объекта PickList