Ссылка. Автоматическое уничтожение объектов

http://www.delphinotes.ru/2010/11/blog-post.html

(+) http://programmingmindstream.blogspot.ru/2015/08/blog-post.html?showComment=1438587877556#c8062249357996846238

Ну и мотивация - "чтобы не переключаться между методами" - убивает конечно... С "другой планеты" я видимо...

Я не между методами переключаюсь, а "квадраты рисую"...

Другой уровень абстракции...

Ну и в конце концов - есть синглетоны (https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D0%BD%D0%B3%D0%BB%D1%82%D0%BE%D0%BD_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)) есть подсчёт ссылок (http://18delphi.blogspot.ru/2013/04/iunknown.html).

Есть Component <-> Owner в конце-концов.

"А чтобы по списку не "пробегать" вручную, список FAutoFreeObjects должен быть типа TObjectList из модуля Contnrs. При уничтожении FAutoFreeObjects, все объекты этого списка будут уничтожены автоматически в порядке, обратном добавлению объектов."

TObjectList - это вообще - беда - "Сокровенные" заповеди

Вот:

"

1. TObjectList. НИКОГДА, кроме случаев совместимости со стандартными библиотеками. Есть Tl3ObjectRefList, Tl3CObjectRefList, Tl3CBaseRefInterfacedList, Tl3SimpleObjectRefList, l3UncomparabeObjectRefList,l3ObjectRefList и т.п. Re: Утечки памяти при работе программ БЧ.

   Достаточно положить один объект в два таких списка (TObjectList) и всё. Костей не соберёшь.

"

"Моё отношение к повсеместному использованию "умных" указателей и интерфейсов ради единственной цели - автоматического уничтожения объектов -- отрицательное. Каждый механизм нужно использовать для тех целей, для которых он предназначен..."

-- смешно читать это прочитав весь приведённый код...

Правда всё "для нужных целей"?

По-моему - "плясать надо" не от "переключения между методами", но от "предметной области" и "мета-модели".

Даже приведённую выше парадигму я бы сделал по-другому. По аналогии с Component <-> Owner.

Вот это:

  FSomeObject1 := TSomeObject1.Create;
  FAutoFreeObjects.Add(FSomeObject1);

Заменил бы на это:

  FSomeObject1 := TSomeObject1.Create(FAutoFreeObjects);

-- чтобы уж мимо FAutoFreeObjects - не пройти. Ну или nil в конструктор передавать. Если нужно. Тогда ты "сам себе злобный бурантина".

А то как сейчас это всё написано - я называю - "ниточки и верёвочки".

За ниточку потяни и верёвочка - отвалится.

А надо, чтобы компилятор "бил по рукам" и не давал "сделать неправильно".

Ну или генератор кода из UML.

А не полагаться на знание "в мозгах автора".

А вообще говоря - я бы всё это на UML нарисовал бы.

С указанием времени жизни объектов. И их взаимных связей.

Ну и вот это:

...

procedure TForm1.OnCreate(Sender: TObject);
begin
FAutoFreeObjects := TObjectList.Create;
...
end;

...

procedure TForm1.OnDestroy(Sender: TObject);
begin
  FreeAndNil(FAutoFreeObjects);
end;

-- примешал бы к TForm1 в качестве примеси:

https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=18delphi%20%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%81%D0%B8

О шаблонах и примесях
Коротко. Много написал про "примеси и шаблоны"
И ещё раз про "примеси". Теперь - "серьёзно"

Ну и перекрыл бы Create и Destroy, а не OnCreate и OnDestroy, ибо OnDestroy - не всегда вызывается. В критических ситуациях. Проходили.

Хотя я могу конечно с DestroyWnd путать.

Ну а вообще - "переключение между методами" - не должно вести к проектным решениям. Это моё глубокое убеждение.