Описанная здесь методика не является

Описанная здесь методика не является панацеей от плохого программирования и других сложностей, которые сам себе создает программист. Но в ряде случаев она может позволить построит более "прозрачную" систему и облегчить ее сопровождение. При "правильном" проектировании в последствии будет легче или перевести всю систему на COM , или довесить основное приложение OLE автоматизацией . Во всяком случае, данный способ позволит относительно безопасно потренироваться на "рабочем проекте", поизучать интерфейсы и работу с ними и т.д. Способы ее использования ограничены лишь вашей фантазией программиста.
У данной методики, несомненно, есть и недостатки. Точнее особенности, на которые следует обратить внимание.

Наследование интерфейсов есть наследование интерфейсов, но не реализации. Реализацию каждый раз придется писать заново. Это в худшем случае. Но ничто не мешает создать "базовый" набор классов, содержащий реализации основных интерфейсов, оформить их в пакет и использовать в дальнейшем (дописывая лишь индивидуальные особенности) .
Освобождать интерфейсы напрямую нельзя. Delphi это делает автоматически, вызывая неявно функцию _Release. Точно так же, при инициализации интерфейса неявно вызывается функция _AddRef. Эти функции оперируют так называемым "счетчиком ссылок" - целой переменной. хранящейся в объекте. _AddRef его увеличивает, а _Release уменьшает. Когда счетчик ссылок станет равным нулю, функция _Release может вызвать метод Free объекта, содержащего интерфейс. А последнее обстоятельство чревато внезапным исключением, приводящим к катастрофе всего приложения. Следует проследить за этим обстоятельством. Одним из способов его обхода является явный вызов _AddRef в конструкторе объекта - это гарантировано увеличит счетчик на 1 и позволит объекту оставаться в памяти до явного вызова деструктора. Однако такое встречается довольно редко. Во всяком случае, обычные наследники TComponent не имеют счетчика ссылок, а _AddRef и _Release ничего не делают и всегда возвращают -1 . А вот с наследниками TInterfacedObject следует быть осторожным…
Существует опасность использование интерфейса объекта, который был удален. Например, приложение запрашивает у plugin'а какой-либо интерфейс, и начинает с ним работать. А plugin, как последняя редиска, вдруг выгружается. В итоге у приложения в руках оказывается ссылка на VMT, которой в действительности уже нету. Естественно, это ошибка программиста и за этим нужно следить.
После того как интерфейс описан и начал использоваться - он не подлежит изменению . Если что-то нужно к нему добавить, следует сделать его наследника.
Эту методику можно и в случае обыкновенных dll. Только (при компиляции dll без пакетов) следует иметь ввиду, что глобальный объект Application у приложения и dll будут разными и для доступа к главной форме из dll в последнюю надо будет передать Application из exe. При компиляции с VCL50 этого делать не нужно.
Наверное, существует что-то еще (что определиться опытным путем в дальнейшем или умные люди подскажут …

Содержание Назад Вперед