🚀 go-pugleaf

Tytułem wstępu
Główne założenie jest takie aby program nie wiedział nic o zawartości klas 
implementujących interfejsy znajdujących się w dll.
Interfejsy są tworzone w dll a program w zasadzie nic nie wie o klasie 
implementującej interfejs.
Interfejs tylko obrabia dane nie przechowuje ich.
Przed każdą operają interfejs ma przydzielany wskaźnik na dane i dopiero je 
obrabia.

Nie ma problemu gdy mam tylko obrobić jednorazowo dane i dalej następne.
Niestety problem gdy dane muszą "współpracować" ze sobą -> Jedne dane muszą 
"powiadomić" inne o swojej zmianie itd.


>> CONST NazwaObiektu = 'Etykieta1';
>>
>> procedure CIPitDraw(out Obiekt: IPitDraw; out ObiektName : String);
>> begin
>> Obiekt:=TEtykieta1.Create;
>> ObiektName:=NazwaObiektu;
>> end;
> Po co Ci osobne ObiektName (poza tym - łat a kul name, takie 
> ingliszpolskie :D)?
Nawyki amatora.
> Pewnie, żeby używać w TDictionary - tak?
Nie wzorzec obserwator i problemy z jego implementacją.

> Skoro tak, to dlaczego nie trzymasz ObiektName w IPitDraw??
Nie, mam TDictionary i to jest główna lista interfejsów.
W IPITDraw jest ObiektName dziedziczący w wyzszego interfejsu.

Ten ObiektName w dll jest tylko po to aby podczas wczytywania dll wiedzieć 
jaki obiekt obsługuje wtyczka/dll bez tworzenia interfejsu.


> A dlaczego nie dodasz metody fabrykującej instancję do interfejsu?
>  IPitDraw = interface(IObiekt)
>  ['{E4FE2E92-7B11-4ABB-BBA6-FBA87BA11387}']
>    function CreateInstance : IObiekt;
>  end;
> Wtedy każda instancja interjsu może tworzyć nowe instancje samego siebie.
>
> Albo, możesz utworzyć interfejs fabryki który będzie fabrykował 
> interfejsy...
> Czyli oddelegować fabrykowanie do osobnego insterfejsu - Twoja procedura 
> CIPitDraw jest taką fabryką.

Dzięki dodałem do interfejsu
procedure CreateInstance(out   Obiekt: IPitEdit; Out ObiektName : String);
i działa tak jak chciałem.