🚀 go-pugleaf

W dniu 2018-03-07 o 20:59, Roman Tyczka pisze:
/ciach/

>> Host zawiera tylko interfejsy.
>> Ich implementację dostarcza konkretna klasa, która rejestruje się w
>> Host. Host nie ma pojęcia o tej klasie, ona tylko trzyma referencję na
>> interfejs.
>> I dlatego nie mam Circular Unit Reference (Circular Class Reference).
> 
> Ale u Ciebie to jest jednokierunkowe, a Przemkowi chodziło o to, żeby
> korowe interfejsy/klasy znały tego Hosta.
W używaniu - tak.
W implementacji, kierunek jest od klasy do hosta.
A poza tym, niech Przemek powie o co mu chodziło ;-)

To co opisałem nie nadaje się do realizacji cyt: "Taka struktura 
drzewiasta  Powiedzmy że nieokreślona na etapie projektowania..."
Tu jest wymagany bardzo dokładny i ściśle określony projekt.

>> To samo dałoby się osiągnąć za pomocą Global Container, ale... pisałem
>> to w czasach kiedy generyków nie było no i mogłby sie pojawić zależności.
>> Poza tym, generyki tu w niczym nie pomogą.
>>
>> I jedna sprawa - nie ma opcji, aby ten sam interfejs był
>> zaimplementowany w runtime przez dwie różne klasy równocześnie.
>> I nigdy nie było mi to potrzebne.
> 
> Tylko, że jedną z idei interfejsu jest właśnie możliwość użycia wielu
> implementacji tego samego interfejsu. To też jest clue systemów opartych na
> IoC.
Po pierwsze, to tu nie jest IoC (IoC u mnie jest używane inaczej i do 
innych celów).
Po drugie, napisałem równocześnie, a nie że w ogóle.
Bp np. w zależności od konfiguracji (i tak mam dokładnie, bo np. Intf 
AppClient jest zaślepiony dla usług, a Host.Misc.Dialogs jest kierowany 
do loggera) może być implementowane jak się chce.

>>> Wydaje mi się, że budowanie takiego interfejsu w pewnym momencie byłoby problemowe - a może nie?
>> Nie jest.
>> Interfejs jest stały, praktycznie się nie rozwija, jeśli się już
>> wszystkie potrzebne usługi się zaimplementuje.
>> Osobiście nie tykam tego latami.
>> Implementację owszem, ale sam korowy interfejs jest praktycznie stały.
>>
>>> I zdaje sobie sprawę, że chce napisać coś, co jest silnie powiązane, a tendencje są takie żeby tego nie robić...
>> Tam raczej nie ma powiązań twardych - jedna usługa w Host nie zależy od
>> innej, ale może jej używać. Poza tym, jeśli nawet są jakieś powiązania,
>> to tylko od interfejsów, a nie od konkretnej ich implementacji.
>>
>> A praktyka pokazała, że najważniejsze jest co innego; wystarczy jeden w
>> uses jeden moduł, gdzie zadeklarowano Host i masz dostęp do wszystkiego.
>> To bardzo wygodne.
> 
> No nie do końca, samo uses linkujące do Hosta to często będzie za mało, gdy
> metoda klasy korowej wymaga parametru o typie zdefiniowanym w jej unicie.
Dlatego trzeba to pisać możliwie prosto. Albo używając typów prostych, 
albo deklarując parametry w jak najmniejszej liczbie modułów.
To w końcu CORE ma być czy co?

Upraszając, u mnie core to jest core.
Wszystko fikuśne to IoC/DI.

-- 
wloochacz