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