значит я обязан для каждого класса, реализующего любой интерфейс, определять методы подсчета ссылок?

нет.
можно вместо TObject наследоваться от TInterfacedObject.

Вот я этого не понимаю. С чего это любой интерфейс должен включать методы, занимающиеся подсчётом ссылок?


Не вариант. Множественного наследования реализации у нас нет. Появляется проблема в выборе TInterfacedObject или чего-то ещё, не наследющегося от этого класса.

  

И не надоедает же об одном и том же спорить...   

не появляется. 
любой класс без указания явного предка - наследник TObject. TInterfacedObject - прямой потомок TObject, ничего, кроме реализации подсчета ссылок, к предку не добавляющий. Зачем вместо TInterfacedObject использовать TObject, если они идентичны за исключением подсчета ссылок? Только ради проблем?

nickless, не об одном. Акценты смещаются. 

на эту тему тоже стоит подписаться

Mayk, 
подписка не бесплатна     

Блин, не от TObject. Я хочу наследоваться от некоторого TMyObject - а он не наследуется от TInterfacedObject. В то же время я хочу реализовать некий Interface1. Я вынужден также реализовывать подсчёт ссылок, который Interface1 наследует от IUnknown - хотим мы того или нет. Наследоваться одновременно и от TMyObject, и от TInterfacedObject я не могу. И вопрос - зачем мне лишние труды по реализации ненужного мне подсчёт ссылок?!


 

Любитель, TMyObject в любом случае наследуется от TObject, потому все изменение сводиться лишь к замене TObject на TInterfacedObject. Не пойму в чем проблема?

если твой TMyObject не доступен тебе для редактирования, то ты можешь объявить собственного наследника TMyObject, который реализует IUnknown(методы объявленные в нем). И использовать в своих проектах TMyMyObject = class(TMyObject) implements IUnknown в качестве базы.
Если ты не хочешь реализовывать три метода, сделай композицию с объектом TInterfacedObject и передай реализацию методов IUnknown внутреннему объекту класса TInterfacedObject.

Добавлено через 6 минут и 9 секунд

предчувствуя возражения типа "это же не удобно! меня поплющит три строчки дописать и объявить внутренний объект" сразу привожу контраргументы:
(по реализации) если объектов будет слишком много, объект, реализующий подсчет ссылок и правда - лишняя трата: либо делать-таки "ручную"(непосредственную) реализацию методов, либо использовать шаблон "Посетитель"(visitor)
(по структуре) композиция вполне соответствует "духу ООП", а перенос реализации на внутренние объекты - полне нормально при условии отсутствия множественного наследования; к тому же само по себе делегирование - не есть плохо, лишь бы логика одного объекта не переносилась в независимый и несвязанный по модели объект.

Это всё хорошо, вопрос в том - нафига мне вообще заботиться о подсчёте ссылок, который мне вовсе не нужен, если я хочу релизовать некий интерфейс, не имеющий никакого отношения к подсчёту ссылок?

Вообщем, думаю мы друг друга поняли. Нигде больше реализация произвольного интерфейса не заставляет реализовывать подсчёт ссылок (почему вообще именно подсчёт ссылок - мож ещё какую-нибудь полезную фиговину реалдизовать   ). Предлагаю переключаться на другой пункт обсуждения (чтоб придумать?  )

Добавлено через 46 секунд

Надо змаенить TMyObject на THisObject 

  Ну вот, это не просто фиговина, а управление памятью. Кстати интерфейс является автоматическим объектом. Это значит что при выходе интерфейса из блока счетчик ссылок декремнируется автоматически и если он становиться равным нулю, то объект автоматом удаляется, без явного вызова Free или деструктора. Тоже удобная фича. Так что не нада.

Гы. Это собственно и называется смарт-поинтер. И непонятно, почему сие обязано привзываться к интерфейсам. 

  Сие называется автоматические объекты. И никак это не привязывается к интерфейсам, просто интерфейс это один из 3х типов автоматических объектов.