🚀 go-pugleaf

On Wed, 7 Mar 2018 01:45:20 -0800 (PST), immo wrote:

> Tak się nad tym zastanawiam jak to zrobić ładnie i dlatego proszę Was o
> jakieś propozycje. Żeby nie było, ja coś takiego mam działającego :) i
> napiszę na koniec jak to zrobiłem. Niemniej jest to w bardzo starej
> apce, którą chciałbym częściowo przepisać na nowo stąd moje pytanie, bo
> być może jest "ładniejszy" sposób na wykonanie tego.

Poszedłbym drogą generyków, czyli jakoś tak:

unit z corem:

  ICoreMain = interface
    function CoreConnection : ICoreConnection<ICoreMain>;
  end;

unit z toolem:

  ICoreConnection<I> = interface
    function CoreMain : I;
  end;

-- 
pozdrawiam
Roman Tyczka

On Wed, 7 Mar 2018 01:45:20 -0800 (PST), immo wrote:

> Tak się nad tym zastanawiam jak to zrobić ładnie i dlatego proszę Was o
> jakieś propozycje. Żeby nie było, ja coś takiego mam działającego :) i
> napiszę na koniec jak to zrobiłem. Niemniej jest to w bardzo starej
> apce, którą chciałbym częściowo przepisać na nowo stąd moje pytanie, bo
> być może jest "ładniejszy" sposób na wykonanie tego.

Poszedłbym drogą generyków, czyli jakoś tak:

unit z corem:

  ICoreMain = interface
    function CoreConnection : ICoreConnection<ICoreMain>;
  end;

unit z toolem:

  ICoreConnection<I> = interface
    function CoreMain : I;
  end;

ps. wysyłam post drugi raz, bo mi zniknął poprzedni, nie wiem why

-- 
pozdrawiam
Roman Tyczka

W dniu środa, 7 marca 2018 13:03:42 UTC+1 użytkownik Roman Tyczka napisał:
> On Wed, 7 Mar 2018 01:45:20 -0800 (PST), immo wrote:
> 
> > Tak się nad tym zastanawiam jak to zrobić ładnie i dlatego proszę Was o
> > jakieś propozycje. Żeby nie było, ja coś takiego mam działającego :) i
> > napiszę na koniec jak to zrobiłem. Niemniej jest to w bardzo starej
> > apce, którą chciałbym częściowo przepisać na nowo stąd moje pytanie, bo
> > być może jest "ładniejszy" sposób na wykonanie tego.
> 
> Poszedłbym drogą generyków, czyli jakoś tak:
> 
> unit z corem:
> 
>   ICoreMain = interface
>     function CoreConnection : ICoreConnection<ICoreMain>;
>   end;
> 
> unit z toolem:
> 
>   ICoreConnection<I> = interface
>     function CoreMain : I;
>   end;
> 

Nie wiem czy by to kodu nie zagmatwało za bardzo, w sensie za dużego naddatku kodu :)
Może nie wynikało to z pierwszego posta, ale ten Core może mieć więcej w sobie tych klas, a każda klasa może mieć w sobie także nielimitowaną ich ilość. Taka struktura drzewiasta :) Powiedzmy że nieokreślona na etapie projektowania...

Core
|-Connection
| |-MainConnection
| | |-cosTamX
| | |-...
| | \-cosTamXX
| |-...
| \-ConnectionX
|-Tools
|-Logic
| |-Logic1
| |-...
| \-LogicX
|-OtherFN
|-...
\-OtherFN_X

Wydaje mi się, że budowanie takiego interfejsu w pewnym momencie byłoby problemowe - a może nie?

I zdaje sobie sprawę, że chce napisać coś, co jest silnie powiązane, a tendencje są takie żeby tego nie robić...
Zresztą czytałem gdzieś ze wzorca singletona też nie powinno się używać :P

pozdrawiam,
Przemek O.

On Wed, 7 Mar 2018 04:25:26 -0800 (PST), immo wrote:

>>> Tak się nad tym zastanawiam jak to zrobić ładnie i dlatego proszę Was o
>>> jakieś propozycje. Żeby nie było, ja coś takiego mam działającego :) i
>>> napiszę na koniec jak to zrobiłem. Niemniej jest to w bardzo starej
>>> apce, którą chciałbym częściowo przepisać na nowo stąd moje pytanie, bo
>>> być może jest "ładniejszy" sposób na wykonanie tego.
>> 
>> Poszedłbym drogą generyków, czyli jakoś tak:
>> 
>> unit z corem:
>> 
>>   ICoreMain = interface
>>     function CoreConnection : ICoreConnection<ICoreMain>;
>>   end;
>> 
>> unit z toolem:
>> 
>>   ICoreConnection<I> = interface
>>     function CoreMain : I;
>>   end;
>> 
> 
> Nie wiem czy by to kodu nie zagmatwało za bardzo, w sensie za dużego naddatku kodu :)

Niby skąd? Przecież poza dodaniem generyka <I> nic więcej nie musisz
dopisywać, a dzięki temu likwidujesz zależność.

> Może nie wynikało to z pierwszego posta, ale ten Core może mieć więcej w sobie tych klas, a każda klasa może mieć w sobie także nielimitowaną ich ilość. Taka struktura drzewiasta :) Powiedzmy że nieokreślona na etapie projektowania...

Domyślam się, że tego jest więcej, pisałeś, że to uproszczony przykład.
 
> Wydaje mi się, że budowanie takiego interfejsu w pewnym momencie byłoby problemowe - a może nie?

Nie wiem, nie widzę tych zagrożeń :-)
 
> I zdaje sobie sprawę, że chce napisać coś, co jest silnie powiązane, a tendencje są takie żeby tego nie robić...

Toteż właśnie...

> Zresztą czytałem gdzieś ze wzorca singletona też nie powinno się używać :P

O tym nie chciałem nawet wspominać ;-)

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-03-07 o 13:25, immo pisze:
/ciach/
> Nie wiem czy by to kodu nie zagmatwało za bardzo, w sensie za dużego naddatku kodu :)
> Może nie wynikało to z pierwszego posta, ale ten Core może mieć więcej w sobie tych klas, a każda klasa może mieć w sobie także nielimitowaną ich ilość. Taka struktura drzewiasta :) Powiedzmy że nieokreślona na etapie projektowania...

Takie coś jakby?
http://www.dflex.pl/dflex-ftp/own/dfSampleCode.png

Zwróć uwagę na podświetlony Host.
My to nazywamy Host Plugin Bridge (Bus?), ale to już trochę zaszłość z 
tą nazwą...

Host to kontener na singletony lub fabryki, które dają dostęp do 
korowych (podstawowych) funkcjonalności systemu.
Pisząc Host. mam dostęp do praktycznie wszystkiego co mi potrzebne.
Bez zastanawiania się co gdzie jest i jak tego użyć.

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).

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.

> 
> Core
> |-Connection
> | |-MainConnection
> | | |-cosTamX
> | | |-...
> | | \-cosTamXX
> | |-...
> | \-ConnectionX
> |-Tools
> |-Logic
> | |-Logic1
> | |-...
> | \-LogicX
> |-OtherFN
> |-...
> \-OtherFN_X
> 
> 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.

> Zresztą czytałem gdzieś ze wzorca singletona też nie powinno się używać :P
Odpowiedź jest taka sama jak zawsze - to zależy.

-- 
wloochacz

On Wed, 7 Mar 2018 18:23:31 +0100, wloochacz wrote:

> Takie coś jakby?
> http://www.dflex.pl/dflex-ftp/own/dfSampleCode.png
> 
> Zwróć uwagę na podświetlony Host.
> My to nazywamy Host Plugin Bridge (Bus?), ale to już trochę zaszłość z 
> tą nazwą...
> Host to kontener na singletony lub fabryki, które dają dostęp do 
> korowych (podstawowych) funkcjonalności systemu.
> Pisząc Host. mam dostęp do praktycznie wszystkiego co mi potrzebne.
> Bez zastanawiania się co gdzie jest i jak tego użyć.
> 
> 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.

> 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.

>> 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.
 
-- 
pozdrawiam
Roman Tyczka

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

W dniu środa, 7 marca 2018 21:43:12 UTC+1 użytkownik wloochacz napisał:
> 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 ;-)

Najprościej, żeby z każdego miejsca tego Core, dało się wywołać coś na styl
Core.Connection.ConnectionX, czyli wejście od samego 'spodu', i przy okazji z możliwością zejścia 'w dół' do klasy niżej, czyli jeśli jesteśmy w ConnectionX, to np. parent.ConnectionY (gdzie parent będzie w tym wypadku Connection).

pozdrawiam,
Przemek O.

W dniu 2018-03-08 o 08:46, immo pisze:
> W dniu środa, 7 marca 2018 21:43:12 UTC+1 użytkownik wloochacz napisał:
>> 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 ;-)
> 
> Najprościej, żeby z każdego miejsca tego Core, dało się wywołać coś na styl
> Core.Connection.ConnectionX, czyli wejście od samego 'spodu', i przy okazji z możliwością zejścia 'w dół' do klasy niżej, czyli jeśli jesteśmy w ConnectionX, to np. parent.ConnectionY (gdzie parent będzie w tym wypadku Connection).
OK i jak sobie to wyobrażasz bez silnego typowania?


-- 
wloochacz

W dniu czwartek, 8 marca 2018 13:08:13 UTC+1 użytkownik wloochacz napisał:
> W dniu 2018-03-08 o 08:46, immo pisze:
> > W dniu środa, 7 marca 2018 21:43:12 UTC+1 użytkownik wloochacz napisał:
> >> 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 ;-)
> > 
> > Najprościej, żeby z każdego miejsca tego Core, dało się wywołać coś na styl
> > Core.Connection.ConnectionX, czyli wejście od samego 'spodu', i przy okazji z możliwością zejścia 'w dół' do klasy niżej, czyli jeśli jesteśmy w ConnectionX, to np. parent.ConnectionY (gdzie parent będzie w tym wypadku Connection).
> OK i jak sobie to wyobrażasz bez silnego typowania?

Ale ja to mam zrobione (na tyle na ile wtedy potrafiłem) :) Chce zrobić na nowo i zapoznaje się z opiniami :) trendami :) itd itp. Napiszę jak to mam zrobione, jak wątek umrze i nikt niczego już nie napisze :)

pozdrawiam,
Przemek O.

On Thu, 8 Mar 2018 04:28:32 -0800 (PST), immo wrote:

>>> Najprościej, żeby z każdego miejsca tego Core, dało się wywołać coś na styl
>>> Core.Connection.ConnectionX, czyli wejście od samego 'spodu', i przy okazji z możliwością zejścia 'w dół' do klasy niżej, czyli jeśli jesteśmy w ConnectionX, to np. parent.ConnectionY (gdzie parent będzie w tym wypadku Connection).
>> OK i jak sobie to wyobrażasz bez silnego typowania?
> 
> Ale ja to mam zrobione (na tyle na ile wtedy potrafiłem) :) Chce zrobić
> na nowo i zapoznaje się z opiniami :) trendami :) itd itp. 

> Napiszę jak to mam zrobione, jak wątek umrze i nikt niczego już nie napisze :)

No to ...pisz ;-)

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-03-08 o 13:58, Roman Tyczka pisze:
> On Thu, 8 Mar 2018 04:28:32 -0800 (PST), immo wrote:
> 
>>>> Najprościej, żeby z każdego miejsca tego Core, dało się wywołać coś na styl
>>>> Core.Connection.ConnectionX, czyli wejście od samego 'spodu', i przy okazji z możliwością zejścia 'w dół' do klasy niżej, czyli jeśli jesteśmy w ConnectionX, to np. parent.ConnectionY (gdzie parent będzie w tym wypadku Connection).
>>> OK i jak sobie to wyobrażasz bez silnego typowania?
>>
>> Ale ja to mam zrobione (na tyle na ile wtedy potrafiłem) :) Chce zrobić
>> na nowo i zapoznaje się z opiniami :) trendami :) itd itp.
> 
>> Napiszę jak to mam zrobione, jak wątek umrze i nikt niczego już nie napisze :)
> 
> No to ...pisz ;-)
Popieram.
Bo szczerze to ja nie do końca rozumiem co masz i co chcesz mieć.

-- 
wloochacz

W dniu czwartek, 8 marca 2018 15:08:52 UTC+1 użytkownik wloochacz napisał:
> > No to ...pisz ;-)
> Popieram.
> Bo szczerze to ja nie do końca rozumiem co masz i co chcesz mieć.

Wydawało mi się to jasne i proste to co napisałem.

Dobra - jeszcze raz, ale wyjaśnienie będzie dłuuugie.

Chce mieć w aplikacji jedną klasę Core, z której będzie dostęp do wszystkiego w tej aplikacji, czyli konfiguracji, logiki, fabryki okien, toolsow itd. itp. Singleton. Tak żeby w kodzie aplikacji można było do wszystkiego mieć dostęp pisząc np. coś takiego. Core.Connection.GetNewConnection.ExecSQLScalar.
Dlaczego tak? Bo biorąc wszystko pod uwagę, tak jest najprościej i najbardziej przejrzysto :)
Ale żeby nie było za trywialnie, chcę żeby z samej definicji tej klasy można też było się odwoływać do każdego miejsca w tej klasie, czy to poprzez klasę rodzica, czy przez Core samo z siebie.
Czyli żeby każda klasa która jest w Core miała w sobie przynajmniej wie rzeczy:
Core <- dostęp do głównej klasy Core
i Parent <- dostęp do klasy w której została stworzona ta w której w danym momencie jesteśmy.
Ogólnie każda klasa w Core ma być dziedziczona z klasy bazowej która ma właśnie zdefiniowane te dwie powyżej (Core i Parent).
Mam nadzieję że to jasne.

W tej chwili mam to załatwione przez class helpera :) 8-10 lat temu wydawało mi się to dobre. W sumie działa, ale chciałbym się poduczyć interfejsów, bo na razie to jest stosowałem ale do trochę czegoś innego.

Teraz pokaże jak to mam w kodzie, bo jeśli tamto było nieczytelne, to może to coś wyjaśni:

klasa bazowa: FW.Classes.Core
  TCoreClass = class(TObject)
  strict private
    _CoreObj: TObject;
  public
    constructor Create(aCore: TObject);
    destructor Destroy; override;

    property CoreObj: TObject read _CoreObj write _CoreObj;
  end;

helper: FW.Helpers.Core
uses
  FW.Classes.Core
  ,FW.Core
  ;

type
  TCoreClassHelper = class helper for TCoreClass
    function Core: TCore;
  end;

implementation

function TCoreClassHelper.Core: TCore;
begin
  if assigned(CoreObj) then
    result := CoreObj as TCore
  else
    result := nil;
end;
 
Main unit: FW.Core
uses
  FW.Classes.Core
  ,FW.Connection.Main
  ,FW.Settings.Main
  ,FW.Tools.Main
  ,...  
;

type
  TCore = class(TCoreClass)
  strict private
    fConnection: TConnection;
    fSettings: TSettings;
    fTools: TTools;
  public
    destructor Destroy; override;

    procedure Initialize;
    function DebugModeOn: boolean;

    property Connection: TrisConnection read ConnectionGet write ConnectionSet;
    property Settings: TrisSettings read SettingsGet write SettingsSet;
    property Tools: TrisTools read ToolsGet write ToolsSet;
  end;

gdzie np. ConnectionGet wygląda tak:
function TCore.ConnectionGet: TConnection;
begin
  ConnectionCheck;
  result := fConnection;
end;
procedure TCore.ConnectionCheck;
begin
  if not Assigned(fConnection) then
    fConnection := TConnection.Create(Self);
end;

connection: FW.Connection.Main
uses
  FW.Classes.Core
  ,FW.Classes.MSSQLConnection
  ;

type
  TConnection = class(TCoreClass)
  strict private
    fMain: TMSSQLConnection;
  public
    destructor Destroy; override;
  end;

implementation

uses
  FW.Helpers.Core
  ;


I właśnie chodzi o to uses tutaj (FW.Helpers.Core), to mi daje to, że z każdej klasy która wywodzi się w TCoreClass mogę użyć konstrukcji Core.Connection... cos tam coś tam.

To wszystko powyżej jest poobcinane więc mam nadzieję, że nie uciąłem czegoś co jest istotne :)

I jaki jest problem?

Chciałbym mieć dalej tę samą funkcjonalność ale napisaną dzisiaj :) Dlatego moje pytanie w sumie nie jest jak konkretnie to zrobić, ale jaką drogą iść i jakie macie Wy pomysły na rozwiązanie tego problemu.

Zresztą ten cały "moloch" jest pochodną dyskusji nad frameworkami prowadzonymi w wloochaczem "pare" dobrych lat temu :)

pozdrawiam,
Przemek O.

W dniu sobota, 10 marca 2018 09:59:45 UTC+1 użytkownik immo napisał:

> Chciałbym mieć dalej tę samą funkcjonalność ale napisaną dzisiaj :)

To, co Ty nazywasz funkcjonalnością ja nazywam dependency hell. Dzisiaj powszechnie używa się podejścia Inversion Of Control / Dependency Injection:

- system to zbiór komponentów - można podzielić je na przykład na usługi oraz ich klientów
- każda usługa ma publiczny interfejs oraz prywatną implementację
- klient określa, od których usług jest zależny, poprzez deklarację parametrów konstruktora o typach interfejsowych; usługa też może być klientem
- wszystkie komponenty rejestrujemy w kontenerze IoC, usługi rejestrujemy z użyciem ich publicznych interfejsów
- kontener IoC załatwia automatyzację: wykrywanie zależności, zarządzanie czasem życia komponentów, wreszcie dbaniem o to, żeby każdy komponent dostał te i tylko te usługi, których mu trzeba (od których zależy).

To opis bardzo z grubsza - dużo na ten temat napisano, a same mechanizmy kontenerów IoC z reguły pozwalają na dużo więcej, np. implementację mechanizmu pluginów. Korzyści:

- separacja odpowiedzialności, małe klasy robią jedną rzecz
- segregacja interfejsów, zmianę w 'frameworkowej' części systemu łatwiej kontrolować
- enkapsulacja, bo implementacja core'owych rzeczy jest zawsze prywatna
- testowalność, bo łatwo podmienić usługi, od których zależy testowany kod na ich zmockowane wersje
- skalowalność, bo implementację usługi można podmienić na proxy, które daje dostęp do zdalnie uruchomionej usługi

...a singletony to zło. W systemie powinien być tylko jeden singleton: kontener IoC.

> pozdrawiam,
> Przemek O.

Pozdrawiam,
Virion

W dniu wtorek, 13 marca 2018 13:29:29 UTC+1 użytkownik Mikołaj 'Virion' Milewski napisał:
> W dniu sobota, 10 marca 2018 09:59:45 UTC+1 użytkownik immo napisał:
> 
> > Chciałbym mieć dalej tę samą funkcjonalność ale napisaną dzisiaj :)
> 
> To, co Ty nazywasz funkcjonalnością ja nazywam dependency hell. Dzisiaj powszechnie używa się podejścia Inversion Of Control / Dependency Injection:

IoC nie jest tożsame z DI :) 
Poza tym - nie rozumiem o co Ci chodzi :) Chyba że o to, że koniec końców w aplikacji widoczne jest to jako obiekt który ma w sobie obiekty :P

> - system to zbiór komponentów - można podzielić je na przykład na usługi oraz ich klientów
> - każda usługa ma publiczny interfejs oraz prywatną implementację
> - klient określa, od których usług jest zależny, poprzez deklarację parametrów konstruktora o typach interfejsowych; usługa też może być klientem
> - wszystkie komponenty rejestrujemy w kontenerze IoC, usługi rejestrujemy z użyciem ich publicznych interfejsów
> - kontener IoC załatwia automatyzację: wykrywanie zależności, zarządzanie czasem życia komponentów, wreszcie dbaniem o to, żeby każdy komponent dostał te i tylko te usługi, których mu trzeba (od których zależy).
> 
> To opis bardzo z grubsza - dużo na ten temat napisano, a same mechanizmy kontenerów IoC z reguły pozwalają na dużo więcej, np. implementację mechanizmu pluginów. Korzyści:
> 
> - separacja odpowiedzialności, małe klasy robią jedną rzecz
> - segregacja interfejsów, zmianę w 'frameworkowej' części systemu łatwiej kontrolować
> - enkapsulacja, bo implementacja core'owych rzeczy jest zawsze prywatna
> - testowalność, bo łatwo podmienić usługi, od których zależy testowany kod na ich zmockowane wersje
> - skalowalność, bo implementację usługi można podmienić na proxy, które daje dostęp do zdalnie uruchomionej usługi

Przeczytałem i nadal nie rozumiem. Pomijając kwestie interfejsów oraz usług i DI to całą reszta mniej więcej dokładnie opisuje to co mam.

Przecież nie będę tłumaczył że jest to framework niezależny od jakiejkolwiek aplikacji gdzie na podstawie konfiguracji dostarczanej mu z dowolnego miejsca niejako buduje sobie aplikacje i sposób jej działania?
Dlatego chce mieć singletona bo nie ma potrzeby żeby była więcej niż jedna instancja frameworka (bo to nawet niewskazane), chce mieć wszystko usystematyzowane i poukładane, tak aby dostęp do podstawowych 'niezmiennych' funkcjonalności był jednakowy. Rozszerzenia logiki dostępne przez dllki, formy generowane przez fabrykę na podstawie metadanych...

Zresztą z tego powodu nie chciałem wchodzić w dywagacje nad tym czym to jest, ale o pomysły jak to wykonać po dzisiejszemu zachowując funkcjonalność, bo nie wyobrażam sobie pracy nad czymś co nie jest usystematyzowane.

> ...a singletony to zło. W systemie powinien być tylko jeden singleton: kontener IoC.

Zło a jednak sam to proponujesz :) Nie ma znaczenia czy dla kontenera IoC czy dla czegoś innego. Zresztą, ja już pisałem że to jest strasznie uproszczone dla potrzeb pokazania tutaj samego schematu działania a nie tego jak to faktycznie jest zrobione. I to tylko kwestia nazewnictwa czy Ty to nazwiesz kontener IoC w którym trzymasz wszystko, czy ja to nazwę Core i trzymam dokładnie to samo.

pozdrawiam,
Przemek O.

W dniu wtorek, 13 marca 2018 15:04:00 UTC+1 użytkownik immo napisał:

> Poza tym - nie rozumiem o co Ci chodzi :) Chyba że o to, że koniec końców w aplikacji widoczne jest to jako obiekt który ma w sobie obiekty :P

Różnica jest zasadnicza:
- w Twoim podejściu zależności są zaszyte w kodzie, co znakomicie utrudnia, jeśli nie uniemożliwia zarządzanie nimi - np. bez 100% pokrycia kodu testami możemy nie wiedzieć, że kod używa zależności, która nie jest spełniona,
- przy użyciu mechanizmów DI zależności są zadeklarowane w interfejsie klasy np. jako parametry konstruktora, co jest przejrzyste i pozwala na automatyzację, ale jest też bezpieczniejsze - zależności są rozwiązywane w momencie tworzenia instancji klasy.

Do tego dochodzą takie kwestie, jak np. możliwość zmiany modelu czasu życia usługi - jedna zmiana w konfiguracji i zamiast singletona, mamy instancję serwisu per klient, jeśli akurat zajdzie taka potrzeba.

> Przeczytałem i nadal nie rozumiem. Pomijając kwestie interfejsów oraz usług i DI to całą reszta mniej więcej dokładnie opisuje to co mam.
> 
> Przecież nie będę tłumaczył że jest to framework niezależny od jakiejkolwiek aplikacji gdzie na podstawie konfiguracji dostarczanej mu z dowolnego miejsca niejako buduje sobie aplikacje i sposób jej działania?

Wszystko pięknie. Pytanko: czy przypadkiem nie dostarczasz zawsze kompletu usług frameworka, niezależnie od tego, jaki podzbiór 'pluginów' jest wybrany do danego wdrożenia - niezależnie od tego, czy dana usługa faktycznie jest użyta przez którykolwiek plugin?

> Dlatego chce mieć singletona bo nie ma potrzeby żeby była więcej niż jedna instancja frameworka (bo to nawet niewskazane), chce mieć wszystko usystematyzowane i poukładane, tak aby dostęp do podstawowych 'niezmiennych' funkcjonalności był jednakowy. Rozszerzenia logiki dostępne przez dllki, formy generowane przez fabrykę na podstawie metadanych...

Nie znam lepszej formy na 'usystematyzowanie i poukładanie' zależności w kodzie niż zautomatyzowanie tego zadania za pomocą kontenera IoC.

> > ...a singletony to zło. W systemie powinien być tylko jeden singleton: kontener IoC.
> 
> Zło a jednak sam to proponujesz :) Nie ma znaczenia czy dla kontenera IoC czy dla czegoś innego. Zresztą, ja już pisałem że to jest strasznie uproszczone dla potrzeb pokazania tutaj samego schematu działania a nie tego jak to faktycznie jest zrobione. I to tylko kwestia nazewnictwa czy Ty to nazwiesz kontener IoC w którym trzymasz wszystko, czy ja to nazwę Core i trzymam dokładnie to samo.

To nie ja proponuję, tylko JAKIŚ stan globalny w programie zawsze będzie. Im go mniej, tym lepiej.

Kontener ma tą przewagę nad Twoim Core, że jego struktura jest dynamiczna, przyjmie wszystko - oraz że kontener jest raczej bytem 'z boku', który tylko łączy ze sobą klocki, a nie punktem dostępowym do funkcjonalności frameworka - nigdy nie powinno być potrzeby jawnego odwoływania się do kontenera z poziomu serwisów ani klientów.

> pozdrawiam,
> Przemek O.

Pozdrawiam,
Virion

W dniu 2018-03-13 o 15:03, immo pisze:
> Przeczytałem i nadal nie rozumiem. Pomijając kwestie interfejsów oraz usług i DI to całą reszta mniej więcej dokładnie opisuje to co mam.
Nie dziwię się, bo to masło maślane bez konkretów z dużą ilością 
nowoczesnej nowomowy.
A kolega Virion niech sobie przypomni pewien niemłody już termin: YAGNI, 
które jest jednym z zasad XP (extreme programming) - dzięki Jacek!
Czyli: "Zawsze implementuj to, czego faktycznie potrzebujesz, ale nigdy 
wtedy, kiedy przewidujesz, że tego potrzebujesz".

Bo, imo, Przemek wcale Ci to maślane DI/IoC niepotrzebne. A na pewno nie 
takie jak to opisuje Virion.

PS.
Na każdy argument i wow Viriona mam konkretną kontrę.
Ale nie chce mi się, nie mam czasu, musiałbym pojechać Virionowi po 
rajtkach, a to zły czas na takie wycieczki.

A poza tym to nic nie wniesie, bo każdy ma swoje widzi-mi-się.

Ale jedno Ci powiem Przemek z doświadczenia; żeby to dobrze, 
elastycznie, poprawnie zaprojektować, używać i aby to niosło realną 
wartość dodaną wg pryncypiów IoC/DI potrzebne są umiejętności i 
doświadczenie obejmujące zarówno architekturę, programomanie i model 
dziedziny powyżej mocnej średniej.
Inaczej taki kod staje się nie do utrzymania.
A wszelkie rady internetowych guru osobiście polecam traktować jako 
lekkie zalecenie, a nie święty gral.
Pamiętaj, worse is better (to z kolei "New Jersey style")!

-- 
wloochacz

W dniu środa, 14 marca 2018 09:46:10 UTC+1 użytkownik wloochacz napisał:

> A wszelkie rady internetowych guru osobiście polecam traktować jako 
> lekkie zalecenie, a nie święty gral.

Kolega Przemek pytał, "jak to się dzisiaj robi" - no, to odpowiedziałem. Jeśli to winduje mnie do rangi internetowego guru - cóż, dziękuję =) Co do graala - pełna zgoda. To jest fajne w programowaniu, że każdy może rozwiązywać problemy po swojemu. Ale to jest też największe ryzyko w programowaniu - trzeba to umieć zrównoważyć i tyle.

> -- 
> wloochacz

Pozdrawiam,
Virion

On Wed, 14 Mar 2018 01:53:39 -0700 (PDT), Mikołaj 'Virion' Milewski wrote:

>> A wszelkie rady internetowych guru osobiście polecam traktować jako 
>> lekkie zalecenie, a nie święty gral.
> 
> Kolega Przemek pytał, "jak to się dzisiaj robi" - no, to odpowiedziałem. 

Na pewno tak spytał? A nie tak:

"Zastanawiam się jak byście rozwiązali taki problem:

Ma być jedna klasa (Singleton) główna - tzw Core.
Ma w sobie mieć inne klasy ale zaimplementowane w taki sposób, żeby [...]"?

;-)

-- 
pozdrawiam
Roman Tyczka

W dniu środa, 14 marca 2018 10:50:31 UTC+1 użytkownik Roman Tyczka napisał:
> Na pewno tak spytał? A nie tak:

Tak:

> Chciałbym mieć dalej tę samą funkcjonalność ale napisaną dzisiaj :) Dlatego moje pytanie w sumie nie jest jak konkretnie to zrobić, ale jaką drogą iść i jakie macie Wy pomysły na rozwiązanie tego problemu. 

:-)

> pozdrawiam
> Roman Tyczka

Pozdrawiam,
Virion

> > Przeczytałem i nadal nie rozumiem. Pomijając kwestie interfejsów oraz usług i DI to całą reszta
> > mniej więcej dokładnie opisuje to co mam.
> Nie dziwię się, bo to masło maślane bez konkretów z dużą ilością nowoczesnej nowomowy.
> A kolega Virion niech sobie przypomni pewien niemłody już termin: YAGNI, które jest jednym z zasad
> XP (extreme programming) - dzięki Jacek!
> Czyli: "Zawsze implementuj to, czego faktycznie potrzebujesz, ale nigdy wtedy, kiedy przewidujesz,
> że tego potrzebujesz".
>
> Bo, imo, Przemek wcale Ci to maślane DI/IoC niepotrzebne. A na pewno nie takie jak to opisuje
> Virion.

Do tej pory nie odzywałem się w tym wątku, bo uznałem, że zwolennicy intejesowania wszystkiego
i tak mnie zakrzyczą, ale po takim wpisie Wloochacza pozwolę sobie podrzucić wam jednego linka,
bo sądzę, że dylematy Przemka dokładnie pasują do rozważań tam zawartych:
https://www.luxoft-training.pl/wiadomosci/zasada-yagni-/

I jeszcze jedna uwaga do Przemka: jeśli zdecydujesz się na budowanie swojego Cora na klasach
z mocnym typowaniem danych, a nie na interfejsach, to daj mi znać. Mogę podrzucić Ci kilka uwag,
jak się do tego zabrać, jeśli powstrzymują Cię jedynie problemy techniczne typu Circular Reference.

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/ 

W dniu środa, 14 marca 2018 18:50:47 UTC+1 użytkownik Krzysztof Szyszka napisał:

> I jeszcze jedna uwaga do Przemka: jeśli zdecydujesz się na budowanie swojego Cora na klasach
> z mocnym typowaniem danych, a nie na interfejsach, to daj mi znać. Mogę podrzucić Ci kilka uwag,
> jak się do tego zabrać, jeśli powstrzymują Cię jedynie problemy techniczne typu Circular Reference.

Oj, to nie doczytałeś :)

Ja już takie coś na "silnym typowaniu" mam. I to od prawie 10 lat.
Zresztą tak naprawdę kiedyś tak było, teraz już wielka część jest niezależna na interfejsach.
W sensie - samo Core jest powiązane (w sensie to Core.Connection.cos tam), ale samo "coś tam" jest już pluginem implementującym interfejs wymagany przez Connection. Stąd może być dowolnym czymś rejestrowanym z konfiguracji).

Natomiast czytając choćby "Programowanie w języku Delphi" Nicka Hodgesa stwierdziłem że niektóre rzeczy można by poprawić. Tak dla zabawy i nabrania wprawy. Być może gdyby mi to się spodobało, to podmieniłbym oryginalny Core. Ale nie mam na to jakiegoś parcia "produkcyjnego" czy palącej potrzeby zmiany.

I w sumie się zastanawiałem nad tym co Virion pisał o kontenerze IoC i stwierdziłem że to nie dla mnie :)

Bardziej mi pasuje dostęp hierarchiczny niż ten oferowany przez kontener. Chociaż to kwestia gustu.

Tym bardziej, że w Core (w trakcie działania aplikacji) ja trzymam także jej stan, a z tego co wiem (chyba że nie wiem) to w kontenerze IoC nie trzyma się stanu. Wiec zamiast jednego wszechmocnego Core miałbym kilka cosiów i kontener z klasami do użycia :P
(wiem, teraz przesadzam w drugą stronę).

pozdrawiam,
Przemek O.

W dniu czwartek, 15 marca 2018 07:54:33 UTC+1 użytkownik immo napisał:

> I w sumie się zastanawiałem nad tym co Virion pisał o kontenerze IoC i stwierdziłem że to nie dla mnie :)
> 
> Bardziej mi pasuje dostęp hierarchiczny niż ten oferowany przez kontener. Chociaż to kwestia gustu.
> 
> Tym bardziej, że w Core (w trakcie działania aplikacji) ja trzymam także jej stan, a z tego co wiem (chyba że nie wiem) to w kontenerze IoC nie trzyma się stanu. Wiec zamiast jednego wszechmocnego Core miałbym kilka cosiów i kontener z klasami do użycia :P

Kontenery IoC z reguły pozwalają na konfigurację czasu życia każdego z serwisów z osobna. To znaczy, że jeśli jakiś serwis ma być singletonem, to tak to konfigurujesz i jest :-) "Lepsze" kontenery (jak AutoFac dla .NET albo ten z Angulara) pozwalają na tworzenie zagnieżdżanych zakresów (nestable scopes): http://autofaccn.readthedocs.io/en/latest/lifetime/

> (wiem, teraz przesadzam w drugą stronę).

God Object? ;-) A bardziej serio, to do opisu problemów Waszego Core Object chyba najbardziej pasuje ten antywzorzec:

http://deviq.com/static-cling/

Jak mówiłem na wykładzie we wrześniu: jeśli tylko wiesz, DLACZEGO chcesz/potrzebujesz złamać jakąś regułę - łam ją. To wolny kraj i wolny zawód. Mi bardziej pasuje kontener, wiele różnych firm i ich platform też na to rozwiązanie przeszło (Google - Angular, Microsoft - ASP.NET, etc), więc go polecam. Tylko tyle i aż tyle.

> pozdrawiam,
> Przemek O.

Pozdrawiam,
Virion

W dniu czwartek, 15 marca 2018 12:23:58 UTC+1 użytkownik Mikołaj 'Virion' Milewski napisał:

> Kontenery IoC z reguły pozwalają na konfigurację czasu życia każdego z serwisów z osobna. To znaczy, że jeśli jakiś serwis ma być singletonem, to tak to konfigurujesz i jest :-) "Lepsze" kontenery (jak AutoFac dla .NET albo ten z Angulara) pozwalają na tworzenie zagnieżdżanych zakresów (nestable scopes): http://autofaccn.readthedocs.io/en/latest/lifetime/

Bardzo mocno się nie rozumiemy. Ja o feriach zimowych a Ty o letnich :P

> 
> > (wiem, teraz przesadzam w drugą stronę).
> 
> God Object? ;-) A bardziej serio, to do opisu problemów Waszego Core Object chyba najbardziej pasuje ten antywzorzec:
> 
> http://deviq.com/static-cling/

Nie - nie pasuje.

Ale Ty nawet nie chcesz zrozumieć jaką odpowiedź chciałem uzyskać. 
Chociaż może i Twoją propozycję można potraktować jako odpowiedź.
Przy okazji - nie mam żadnego problemu - wszystko działa dobrze od wielu lat :P

pozdrawiam,
Przemek O.

W dniu czwartek, 15 marca 2018 13:21:42 UTC+1 użytkownik immo napisał:

> Bardzo mocno się nie rozumiemy. Ja o feriach zimowych a Ty o letnich :P

Zawsze wolałem lato :P

> Ale Ty nawet nie chcesz zrozumieć jaką odpowiedź chciałem uzyskać. 

Skoro chciałeś uzyskać konkretną odpowiedź, to po co zadawałeś pytanie? ;-) Celowo zboczyłem z tematu klas typu Core - chwyciłem się tego, że chciałeś też wiedzieć, jak się DZIŚ pisze. Skoro sam kiedyś zrobiłem odwrót od klas typu Core, to mogę się podzielić doświadczeniem, prawda?

> Chociaż może i Twoją propozycję można potraktować jako odpowiedź.

Hmm, a jak inaczej ją można potraktować..? Bo innego celu nie miała, jak wnieść inne spojrzenie na temat dostępu do usług w systemie. Nikogo do niczego nie zmuszam przecież.

> Przy okazji - nie mam żadnego problemu - wszystko działa dobrze od wielu lat :P

Jedno pytanie: piszesz do swojego kodu testy jednostkowe?

> pozdrawiam,
> Przemek O.

Pozdrawiam,
Virion

W dniu czwartek, 15 marca 2018 13:53:51 UTC+1 użytkownik Mikołaj 'Virion' Milewski napisał:
> W dniu czwartek, 15 marca 2018 13:21:42 UTC+1 użytkownik immo napisał:

> Jedno pytanie: piszesz do swojego kodu testy jednostkowe?

Tak, chociaż tego nie lubię.

pozdrawiam,
Przemek O.

W dniu 2018-03-16 o 23:04, immo pisze:
> Tak, chociaż tego nie lubię.

No i cały plan w pi..u, bo Virion twierdzi, że się nie da ich napisać i 
utrzymać jeśli nie będzie to wstrzykiwane do globalnego kontenera :P

-- 
wloochacz

W dniu piątek, 16 marca 2018 23:04:47 UTC+1 użytkownik immo napisał:
> W dniu czwartek, 15 marca 2018 13:53:51 UTC+1 użytkownik Mikołaj 'Virion' Milewski napisał:
> > W dniu czwartek, 15 marca 2018 13:21:42 UTC+1 użytkownik immo napisał:
> 
> > Jedno pytanie: piszesz do swojego kodu testy jednostkowe?
> 
> Tak, chociaż tego nie lubię.

O, witaj w klubie. Z ciekawości, jak mockujesz zależności do swojej klasy Core?

> pozdrawiam,
> Przemek O.

Pozdrawiam,
Virion

W dniu sobota, 17 marca 2018 07:39:27 UTC+1 użytkownik wloochacz napisał:
> W dniu 2018-03-16 o 23:04, immo pisze:
> > Tak, chociaż tego nie lubię.
> 
> No i cały plan w pi..u, bo Virion twierdzi, że się nie da ich napisać i 
> utrzymać jeśli nie będzie to wstrzykiwane do globalnego kontenera :P

A gdzie ja to niby napisałem..? Luzuj!

> -- 
> wloochacz

Pozdrawiam,
Virion

On Sat, 17 Mar 2018 07:39:22 +0100, wloochacz wrote:

>> Tak, chociaż tego nie lubię.
> 
> No i cały plan w pi..u, bo Virion twierdzi, że się nie da ich napisać i 
> utrzymać jeśli nie będzie to wstrzykiwane do globalnego kontenera :P

Napisać się może i da (bo wszystko się da), ale z pewnością DI drastycznie
upraszcza kwestię testów. Żadna sklejona zależnościami superklasa nie
będzie w tym obszarze lepsza, mimo zaklinania rzeczywistości.

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-03-19 o 14:03, Roman Tyczka pisze:
> On Sat, 17 Mar 2018 07:39:22 +0100, wloochacz wrote:
> 
>>> Tak, chociaż tego nie lubię.
>>
>> No i cały plan w pi..u, bo Virion twierdzi, że się nie da ich napisać i
>> utrzymać jeśli nie będzie to wstrzykiwane do globalnego kontenera :P
> 
> Napisać się może i da (bo wszystko się da), ale z pewnością DI drastycznie
> upraszcza kwestię testów. Żadna sklejona zależnościami superklasa nie
> będzie w tym obszarze lepsza, mimo zaklinania rzeczywistości.
Prawda, ale mi raczej chodzi o to, że wcale nie trzeba stosować do tego 
DI, aby sobie z tym poradzić.

-- 
wloochacz

W dniu 2018-03-19 o 10:09, Mikołaj 'Virion' Milewski pisze:
> W dniu sobota, 17 marca 2018 07:39:27 UTC+1 użytkownik wloochacz napisał:
>> W dniu 2018-03-16 o 23:04, immo pisze:
>>> Tak, chociaż tego nie lubię.
>>
>> No i cały plan w pi..u, bo Virion twierdzi, że się nie da ich napisać i
>> utrzymać jeśli nie będzie to wstrzykiwane do globalnego kontenera :P
> 
> A gdzie ja to niby napisałem..? Luzuj!
Jeszce nigdzie - ale powiedz, że nie miałeś tego na myśli? :D
Sam luzuj! Co mnie namawiasz...

-- 
wloochacz

On Mon, 19 Mar 2018 14:40:08 +0100, wloochacz wrote:

>>>> Tak, chociaż tego nie lubię.
>>>
>>> No i cały plan w pi..u, bo Virion twierdzi, że się nie da ich napisać i
>>> utrzymać jeśli nie będzie to wstrzykiwane do globalnego kontenera :P
>> 
>> Napisać się może i da (bo wszystko się da), ale z pewnością DI drastycznie
>> upraszcza kwestię testów. Żadna sklejona zależnościami superklasa nie
>> będzie w tym obszarze lepsza, mimo zaklinania rzeczywistości.
> Prawda, ale mi raczej chodzi o to, że wcale nie trzeba stosować do tego 
> DI, aby sobie z tym poradzić.

Pewnie, że nie trzeba. Nie trzeba w ogóle z wzorców i dobrych praktyk
korzystać, można wszystko kleić do kupy i stosować antywzorce. Kto chcącemu
zabroni?
I nie, nie jestem fanatykiem wzorców, stosuję je tam gdzie ma to
uzasadnienie, ale z pewnością nie czepiałbym się kogoś o to, że je
propaguje. Zwłaszcza w świecie Delphi, gdzie dominuje wzorzec TForm z
metodyką OnClick.

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-03-19 o 15:20, Roman Tyczka pisze:
> On Mon, 19 Mar 2018 14:40:08 +0100, wloochacz wrote:
> 
>>>>> Tak, chociaż tego nie lubię.
>>>>
>>>> No i cały plan w pi..u, bo Virion twierdzi, że się nie da ich napisać i
>>>> utrzymać jeśli nie będzie to wstrzykiwane do globalnego kontenera :P
>>>
>>> Napisać się może i da (bo wszystko się da), ale z pewnością DI drastycznie
>>> upraszcza kwestię testów. Żadna sklejona zależnościami superklasa nie
>>> będzie w tym obszarze lepsza, mimo zaklinania rzeczywistości.
>> Prawda, ale mi raczej chodzi o to, że wcale nie trzeba stosować do tego
>> DI, aby sobie z tym poradzić.
> 
> Pewnie, że nie trzeba. Nie trzeba w ogóle z wzorców i dobrych praktyk
> korzystać, można wszystko kleić do kupy i stosować antywzorce. Kto chcącemu
> zabroni?
> I nie, nie jestem fanatykiem wzorców, stosuję je tam gdzie ma to
> uzasadnienie, ale z pewnością nie czepiałbym się kogoś o to, że je
> propaguje. 
Ty może nie, ale ja na pewno tak.

> Zwłaszcza w świecie Delphi, gdzie dominuje wzorzec TForm z
> metodyką OnClick.
Masz rację.
Ale jednak mało wiesz o tym, że akurat ja Viriona mogę i powinienem się 
czepiać ;-)
Ale to nieważne, ponieważ co do zasady - racja.

-- 
wloochacz

W dniu poniedziałek, 19 marca 2018 10:08:41 UTC+1 użytkownik Mikołaj 'Virion' Milewski napisał:
> W dniu piątek, 16 marca 2018 23:04:47 UTC+1 użytkownik immo napisał:
> > W dniu czwartek, 15 marca 2018 13:53:51 UTC+1 użytkownik Mikołaj 'Virion' Milewski napisał:
> > > W dniu czwartek, 15 marca 2018 13:21:42 UTC+1 użytkownik immo napisał:
> > 
> > > Jedno pytanie: piszesz do swojego kodu testy jednostkowe?
> > 
> > Tak, chociaż tego nie lubię.
> 
> O, witaj w klubie. Z ciekawości, jak mockujesz zależności do swojej klasy Core?

> Pozdrawiam,
> Virion


O Panie... Cały czas piszę, że to co tutaj przedstawiam to wierzchołek góry, li tylko zarys całości. Bo o ile, to co nazywam Core na poziomie logiki do hmm.. funkcjonalności jest "sklejone" przez zależności, to o tyle same funkcjonalności są pod postacią pluginów implementujących interfejsy do tych funkcjonalności. Nie licząc pierdół to większość jest właśnie implementowana w ten sposób. Więc jeśli chcesz sobie coś przetestować to konfigurujesz pustego plugina. 
Same pluginy testujesz osobno bo one są osobnymi bytami które nie muszą nic o sobie i Core wiedzieć.
Jedynie trochę zabawy jest z testowaniem samego logicznego Core. Ale te powiązania są na tyle proste jak już się wie jak one działają że nie jest problemem ich testowanie. Poza tym, tam bardzo bardzo rzadko się coś zmienia.

pozdrawiam,
Przemek O.

W dniu poniedziałek, 19 marca 2018 14:03:52 UTC+1 użytkownik Roman Tyczka napisał:
> On Sat, 17 Mar 2018 07:39:22 +0100, wloochacz wrote:
> 
> >> Tak, chociaż tego nie lubię.
> > 
> > No i cały plan w pi..u, bo Virion twierdzi, że się nie da ich napisać i 
> > utrzymać jeśli nie będzie to wstrzykiwane do globalnego kontenera :P
> 
> Napisać się może i da (bo wszystko się da), ale z pewnością DI drastycznie
> upraszcza kwestię testów. Żadna sklejona zależnościami superklasa nie
> będzie w tym obszarze lepsza, mimo zaklinania rzeczywistości.

A ja odpowiem typowo - To zależy :P

Faktem jest że prościej jest jest w niepowiązanych. Ale to też zależy jak to jest zaprojektowane i napisane.

pozdrawiam,
Przemek O.

W dniu wtorek, 20 marca 2018 13:40:11 UTC+1 użytkownik wloochacz napisał:

> > Zwłaszcza w świecie Delphi, gdzie dominuje wzorzec TForm z
> > metodyką OnClick.
> Masz rację.
> Ale jednak mało wiesz o tym, że akurat ja Viriona mogę i powinienem się 
> czepiać ;-)
> Ale to nieważne, ponieważ co do zasady - racja.

Chyba muszę zacząć pisać tu incognito, może wloochacz przyzna mi czasem rację nie tylko co do zasady, ale i wprost ;-)

> -- 
> wloochacz

Pozdrawiam,
Virion