Для тех, кто регулярно штудирует дельфийские What's New и параллельно читает блоги Марко Канту - это далеко и не новость. Но ИМНО лишний раз поделиться все же стоит.
Речь идет о применении двух относительно новых атрибутах из System.pas А именно WeakAttribute, UnsafeAttribute .
Изначально оба этих атрибута введены для поддержки ARC ( Automatic Reference Counting ) в мобильных поделках на Дельфях.
Без них не получается обойти проблему взаимного увеличения RefCount между ссылающихся друг на друга объектов и как следствие невозможность правильно освободить память основываясь лишь на механизме ARC.

Спрашивается, чем эти атрибуты могут быть полезны для пишущих под Десктоп? А вот чем:
Они позволяют реализовать нечто на подобии т.н. "чистых интерфейсов". Т.е. интерфейсов не обремененных заботой об увеличении/уменьшении числа ссылок и "самообнуляющихся" интерфейсов.
Нет, безусловно создавать минимальную реализацию IInterface, ну или наследоваться от TInterfacedObject или от TSingletonImplementation по любому придется.
Но все же есть интересные нюансы в плане работы с такими интерфейсами.

Возьмем пример более простого UnsafeAttribute


В данном случае можем рассматривать ISI: ISomeInterface как просто своеобразный облегченный Pointer на интерфейс с поддержкой от компилятора.

!!! Но, если вместо вы напишете то _AddRef все же будет вызван, что в случае с TInterfacedObject приведет к увеличению RefCount и тогда на SC.Free вы получите эксепшен из процедурки TInterfacedObject.BeforeDestruction, которая при уничтожении проверяет RefCount на равенство 0.

ИМХО: Как по мне так это очередной баг компилятора. Если уж для Unsafe интерфейсов не вызывается _Release, то и _AddRef тоже не должен вызываться ни при каком синтаксисе.
Но либо можно пользоваться простым присвоением (как в примере). Либо же объекты должны наследоваться от TSingletonImplementation, где и без того учет количества ссылок не важен, но тогда и тогда и этот unsafe не особо-то уже и нужен

Теперь о применении WeakAttribute


!!! WeakAttribute лучше НЕ использовать с объектами, где учитывается RefCount типа TInterfacedObject
Причина в том, что при использовании синтаксиса ISI := SC произойдет "непредвиденный" запуск _Release ( ИМНО Побочный баг ведения списка weak ссылок ) и ваш TInterfacedObject может быть преждевременно уничтожен.
В случае же с TSingletonImplementation и подобных это не важно.

Главный же плюс от применения Weak интерфейсов в том, что они автоматически обнуляются ( переменным присваивается nil ) при уничтожении объекта на который они ссылаются (см. пример).
Т.е. фактически Дельфина теперь ведет managed учет weak ссылок. И это может быть полезно в некоторых схемах, поскольку мы можем узнать об уничтожении главного объекта проверив интерфейсную переменную на nil.

!!! Нужно быть внимательным при объявлении [Unsafe] и [Weak] атрибутов.
Потому как, очень просто случайно написать например Week вместо Weak. Дельфи проглотит это без ошибок и лишь с малозаметным предупреждением типа "W1025 Unsupported language feature: 'custom attribute'", поскольку для него это просто имя некого неимплементированного атрибута. И тогда вместо Weak-интерфейса вы получите обычный и можете об этом и не узнать.

rgreat1. В топку интерфейсы.
2. В топку ARC.А в след за ними в топку и старых заскорузлых отшельников-староверов aka rgreat.
Бо оне дюже мешаютЪ юным отрокам постигать что-то новое и диковинно-заморское.
Поелику интерфейсы они суть благо великое, ежели их православно уготовати, аки они суть в диковинных поделках на C#.

( так даже деду rgreat-у будет понятнее ) ;)

rgreatЯ помоложе многих тут буду. А интерфейсы в дельфях с незапамятных времен есть.
Что не мешает им быть весьма спорным инструментом вне узкого круга задач.
Так что с ретроградностью ты мимо.Возраст он часто в голове. Нередко можно встретить и по-старчески кряхтящих подростков. Особенно часто такие встречаются среди "ботаников".

Интерфейсы же сами по себе это очень полезный инструмент. А-то что он в Дельфях изначально был создан для поддержки COM и поэтому и изначально отягощен явным заданием GUID и поддержкой RefCount - это издержки данной старинной реализации.
Поэтому-то уже давно все и выкручивались с помощью заглушек на _AddRef и _Release как в TSingletonImplementation.
Хотя, возможно нужно было бы просто давно ввести новый тип. Что-нибудь типа "simpleinterface" и все было бы идеологически куда проще.
Пока же имеем, что имеем. Зато вот появляются такие вещи как экзотические для найтива "самообнуляемые интерфейсы".

В любом случае: не хочешь - не пользуйся.
Только когда сама библиотека давно использует интерфейсы вдоль и поперек, говорить что-то типа "в топку интерфейсы" - это как бессмысленно в лужу пер... ;)
( кстати defecator в этом всегда мастер ;) )

rgreatОпиши задачи где интерфейсы есть больше смысла применять чем другие инструменты.
И почему.rgreat, почему я тебе должен хрестоматийные истины расписывать. Или тебе самому лениво посмотреть?
В паре/тройке предложений: interface - это явное отделение собственно "интерфеса" класса от его непосредственной реализации при котором не нужно опираться на единую ветвь наследования. Особенно когда наследование по одной ветви может являться нарушением инкапсуляции либо вообще не возможно или бессмысленно в рамках некоторой архитектуры.

На практике действительно часто либо не имеет смысла и даже вредно, либо принципиально нет возможности создавать иерархию в рамках наследования из одной цепи, но нужен "интерфейс" ( в данном случае можешь понимать "интерфейс" как нечто объединяющее твои возможно весьма разнородные объекты ), который позволит, например, однообразно передавать их в какую-то обобщенную обработку, которая в данном случае не нуждается в знании о всех этих конкретных классах.
Так понятнее? Если нет - читай книжечки про паттерны и прочее.

rgreatВдруг ты мне "глаза откроешь"?
Дык о чем и речь. Область применения интерфейсов в реальной жизни весьма ограничена.
"Глупый ты, Лешка, – улыбнулся полковник. – Прямо беда с тобой. Ты бы хоть книжку какую-нибудь прочитал.
- А зачем, Иван Антонович?
- Хотя, правильно. Тебе может и не к чему." (с) "О бедном гусаре замолвите слово".

Я могу, например, предположить, что либо сложность проектов, с которыми ты пока сталкивался не велика, либо у тебя могут быть серьезные костыли с проектированием больших проектов, либо это твои собственный подход.
Но опять же, лично ты можешь не пользоваться какой-либо возможностью или "механизмом" и вполне себе жить и без этого.
Либо по неумению/незнанию, либо по принципиальному нежеланию. В любом случае - тогда это лично твои тараканы и обсуждать их мы не будем.
Примеры же повсеместного использования интерфейсов ты можешь найти как в самой дельфийской библиотеке, так и во множестве сторонних проектов.
Более того, есть вполне серьезные и резонные измышления о большой полезности "интерфейсного" подхода в проектировании.
Но возможность и полезность - это не значит необходимость. Поэтому лично тебя никто не заставляет.

rgreatЧаще всего в жизни эти самые "List,Queue,DataSet,Form" будут рождены от общего родителя.От какого общего родителя они будут рождены? Ну разве что от TObject-а
У тебя что все объекты в твоих собственных иерархиях в рамках только одной ветви наследуются? Если так - то это "тихий ужас".

rgreatОк, я понял.
У тебя талант говорить глупости с умным видом.
По сути ничего не сказано.Тебе по сути я уже сказал. Тебе даже простенький пример привели. И как раз твои возражения по этому примеру и вызывают вопросики... ;)

Ну еще как пример могу тебе привести, что чисто с прикладной точки зрения ( без каких-то рассуждалок о проектировании ) ты, например, можешь использовать единый интерфейс для сохранения в XML/JSON или еще куда своих разнородных ( не наследуемых от одного предка ) объектов. При этом процедурка не обязана вообще ничего знать о твоих объектах, а только об одном их общем интерфейсике.
Еще раз тебе говорю - это будет удобная возможность, а не обязанность.
Так же как ты, например, можешь и не пользоваться удобством обобщенных списков, а писать все на TList-ах и заниматься приведением. Ты просто не будешь пользоваться более удобным в данном случае "механизмом". Вот и все.

rgreatLeonidУ тебя что все объекты в твоих собственных иерархиях в рамках только одной ветви наследуются? Если так - то это "тихий ужас".Там пошутил, сам посмеялся.
Молодец.Ну а как еще тебя понять?
Если ты очевидные удобства не принимаешь в принципе. Даже когда тебе детально "расжевывают", где это хорошо работает.