Абстракция и интерфейсы в Delphi

Когда «абстрактный класс» не эквивалентен «интерфейсу»

Начинающие нередко путают абстрактный класс с интерфейсом, но для опытного разработчика разница очевидна. Абстрактный класс в Delphi — это просто класс с виртуальными методами (ключевое слово abstract). Он может содержать поля, реализованные методы и конструкторы. Интерфейс (interface) — это совершенно другая сущность: он не наследуется от TObject, а от IInterface (или IUnknown). Профессионалы помнят: интерфейс не имеет полей и не может содержать код реализации. Частая ошибка — пытаться объявить поле в интерфейсе или определить для него конструктор. Компилятор этого не позволит, но в старых проектах иногда встречаются костыли через variant или TObject-касты, что ломает всю архитектуру.

Счётчик ссылок и его ловушки: скрытые риски

Самое популярное заблуждение — что интерфейсы всегда автоматически управляют памятью и можно расслабиться. Реальность иная: если вы смешиваете классические объекты (полученные через Create) и интерфейсные ссылки, вы рискуете получить либо двойное освобождение, либо утечку. Эксперты обращают внимание на правило: никогда не присваивайте интерфейсной переменной объект, полученный через TObject.Create, если этот объект уже имеет внешний владелец. И наоборот: после присвоения нового экземпляра интерфейсу (IMyIntf := TMyClass.Create) не вызывайте Free вручную — счётчик ссылок сделает это за вас. Игнорирование этого нюанса — причина трудноотлавливаемых глюков в многопоточных приложениях.

Неочевидная роль GUID и QueryInterface

Часто думают, что GUID для интерфейсов — формальность. На самом деле без уникального идентификатора вы не сможете безопасно использовать операции as и Supports. Эксперты советуют: всегда объявляйте GUID для интерфейсов, даже если вы уверены, что не будете приводить типы. Иначе QueryInterface будет возвращать E_NOINTERFACE для любого запроса, кроме самого базового. Второй подводный камень: переопределение QueryInterface в собственном классе. Если вы решите перехватить этот механизм (например, для реализации прокси), помните, что стандартная реализация TInterfacedObject уже передаёт управление _AddRef/_Release. Неосторожное переопределение приводит к бесконечной рекурсии или падению при вызове as.

Агрегирование и делегирование: что не пишут в документации

Компонентная модель COM требует поддержки агрегирования, но в Delphi эту возможность используют редко. Между тем, грамотное делегирование вызовов интерфейса одному объекту-помощнику (через TAggregatedObject) позволяет строить гибкие системы без множественного наследования. Специалисты замечают: при агрегировании важно контролировать, что QueryInterface внешнего объекта корректно обрабатывает запросы внутренних интерфейсов. Типичный промах — забыть переопределить QueryInterface у внешнего класса, и тогда внутренние интерфейсы остаются недоступными.

Производительность и вызов методов через интерфейс: мифы

Ходит мнение, что вызов метода через интерфейс всегда медленнее, чем через прямой вызов виртуального метода. На практике разница в современных компиляторах Delphi (начиная с 2007 года) составляет единицы наносекунд из-за прямого вызова через VMT интерфейса. Заметные тормоза появляются только при частом повторном запросе интерфейса через as (он вызывает QueryInterface для каждого приведения). Профессиональный совет: сохраняйте интерфейсную ссылку в локальной переменной внутри цикла, а не вызывайте as на каждой итерации. Второй момент — не кэшируйте ссылки на IInterface для объектов, которые могут быть освобождены раньше: это гарантирует удержание объекта в памяти до выхода из области видимости.

Совместимость со старыми версиями и RTTI

Разработчики, работающие с Delphi 7 или 2007, часто попадают в ловушку: в этих версиях интерфейсы не поддерживают расширенную RTTI для свойств. Если вы пишете компонент, который должен сериализоваться или редактироваться в инспекторе объектов, интерфейсные свойства будут проигнорированы. Выход — использовать коммуникацию через классы или применять паттерн «Фасад». Эксперты отмечают: в Delphi 2010+ появилась поддержка атрибутов для интерфейсов, но даже сейчас не все инструменты (например, ORM) корректно обрабатывают интерфейсные поля без явного GUID. Проверяйте документацию библиотек, а не полагайтесь на «авось».

Практическая рекомендация: когда лучше отказаться от интерфейса

Бытует точка зрения, что интерфейсы обязательны в любом крупном проекте. Однако опыт показывает: для простых утилитарных классов (например, хелперов) интерфейсы излишни. Они добавляют принудительное управление памятью и усложняют отладку из-за неявных вызовов _AddRef. Используйте интерфейсы в точках стыковки подсистем (плагины, слабосвязанные модули, обработчики событий), где важна абстракция без привязки к конкретной иерархии наследования. Если вам нужна просто полиморфная реализация — обычного абстрактного класса с virtual методами достаточно и менее хрупко.

Добавлено: 27.04.2026