🚀 go-pugleaf

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.