#820. Link. Automatic items destroying

Original in Russian: http://programmingmindstream.blogspot.ru/2015/08/blog-post_65.html

http://www.delphinotes.ru/2010/11/blog-post.html (in Russian)

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

I am fed up with the motivation “so that not to switch the methods”... I must be a whole other universe...

I do not switch the methods, I “draw squares”...

This is another level of abstraction...

Finally, there exist singletones  and reference counting.

After all, there exist Component <-> Owner.

"So that not to “look through” the list manually, the FAutoFreeObjects list has to be of the TObjectList kind from the Contnrs unit. When destroying the FAutoFreeObjects, all items of this list are automatically destroyed in the order in which they were added."

TObjectList is actually a disaster Sacred commandments (in Russian).

Look here:

"TObjectList. NEVER except from compatibility with standard libraries. There exist Tl3ObjectRefList, Tl3CObjectRefList, Tl3CBaseRefInterfacedList, Tl3SimpleObjectRefList, l3UncomparabeObjectRefList,l3ObjectRefList and so on. Re: Memory leak of base programs. .
You just need to put one item in two lists (TObjectList) and that’s all. You’ll never come out of it alive."

"i disapprove common usage of “smart” pointers and interfaces solely for automatic destroying of items. A tool has to be used for its intended purposes..."

It makes me laugh to read it after looking at the code given...

Is it really “for required purposes”?

As for me, we need to begin not with “methods switching” but the “domain area” and “metamodel” (in Russian).

I would even do the paradigm in different way, similarly to Component <-> Owner.

I would replace this code:

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

with the following:

FSomeObject1 := TSomeObject1.Create(FAutoFreeObjects);

In so doing, I will not pass by the FAutoFreeObjects and pass nil to the constructor (if needed). I am the boss.

I call such code “strings and small ropes”.

Pull the string or a rope and it falls off.

The compiler has to “slap on the wrist” and prevent from “doing wrong”.

Code generator from UML can also be used.

One should not base on the knowledge of some author.

Actually, I would draw it on UML, defining the items lifetime and interconnections.

I would add the following code:

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

to the TForm1 as a mixin:

https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=18delphi+Mixins

About patterns and mixins
Briefly. I wrote much about “patterns and mixins”  (in Russian)
Once again about “mixins”, now seriously (in Russian)

I would also override Create and Destroy instead of OnCreate and OnDestroy, since OnDestroy can not always be called in an emergencies (you know).

Although, I can confuse it with DestroyWnd.

Generally speaking, I am strongly convinced that “methods switching” should not lead to the design decisions.