inversion of control (IoC) is a design principle in which custom-written portions of a computer program receive the flow of control from a generic framework.
Ale czymże jest ten framework? Czy mam go rozumieć jako framework ASP.NET / framework Java Spring czy może jako kontener IoC czy co? Co autor tej definicji miał na myśli przez słowo "framework" w kontekście inversion of control?
aleksandercherpski2 napisał(a):
Ale czymże jest ten framework? Czy mam go rozumieć jako framework ASP.NET / framework Java Spring czy może jako kontener IoC czy co? Co autor tej definicji miał na myśli przez słowo "framework" w kontekście inversion of control?
tak to jest dokładnie taki Spring (który jest jednocześnie kontenerem IoC).
przymotnik "generic " ma tu pewnie oznaczać, że nie jest specyficzny dla aplikacji, w odróżnieniu od "custom-written" specyficznego dla aplikacji.
Najlepiej zapytać autora co miał na myśli :-) W tym kontekście (design), nie masz implementacji (więc ciężko mówić, że należy to rozumieć jako ASP.NET/Java Spring; można uznać, że to przykład takiego "generic frameworka"), więc rozumiałbym to jako zbiór komponentów programowych, które dostarczają rozwiązań podstawowych problemów pojawiających się często przy tworzeniu różnych rozwiązań (np. logowanie, zarządzanie konfiguracją itp.) Takie komponenty mają określone interfejsy/kontrakty/zasady.
Możesz patrzeć na taki "generic framework" jak na zestaw klocków lego, z którego budujesz różne cuda. Jak podłączysz koła do jakiejś platformy, to zbudowana część będzie jeździć, jak dodasz drzwi to się będą otwierać/zamykać itd.
inversion of control (IoC) is a design principle in which custom-written portions of a computer program receive the flow of control from a generic framework.
Na polski to byłoby przetłumaczone:
Odwrócenie kontroli jest zasadą projektową w której samemu napisane kawałki programu otrzymują kontrolę przepływu od jakiegoś innego frameworka lub biblioteki.
No i w sumie z tym się zgadzam, bo domyślnie (czyli bez IoC) samemu napisane kawałki nie otrzymują jej.
Dosyć dobrze jest to wyjaśnione tutaj: /watch?v=zHiWqnTWsn4 od 28:57 do 52:00.
Ja tylko mam jedną zagwozdke przy tej definicji. Z tym generycznym frameworkiem. Załóżmy iż napisałem 95% aplikacji i zostało mi tylko wstzykiwanie. I teraz mam różne opcje:
I teraz w przypadku 1. i 2. jest to IoC według tej definicji a w przypadku 3. - nie. Chociaż kod aplikacji się nie zmienił, za wyjatkiem tego jednego maina. Zastanawiające
Ja wiem iż to dziwny przypadek ten 3. Z drugiej stony Spring Core powstał na kolanie żeby pokazać iż da się wstrzykiwać w niepatologiczny sposób. Kto pamięta EJB wie co to patologiczne wstrzykiwanie
Inversion of control to słaby termin, bo odnosi się do wielu różnych zastosowań. Samo odwrócenie czegoś, co nie ma określonego zwrotu też jest sus
Za wiki:
such as the Spring framework. In this different sense, "inversion of control" refers to granting the framework control over the implementations of dependencies that are used by application objects rather than to the original meaning of granting the framework control flow (control over the time of execution of application code e.g. callbacks).
Czyli według tego wynika, że IoC w kontekście springa różni się tym od non-IoC, że z IoC framework ma kontrolę nad doborem zależności do poszczególnych komponentów.
is a design principle in which custom-written portions of a computer program receive the flow of control from a generic framework.
To trochę jest podejrzane. Wyobraź sobie, że masz taki kod:
service = spring_pls_give_me_a_wired_service()
service.run()
vs
spring_run_all_beans()
W pierwszym przypadku mamy IoC na poziomie łączenia zależności, ale nie wykonywania kodu aplikacji (poza konstruktorami oczywiście). Drugi przypadek to IoC na pełnej. Pytanie: czy jedna linijka kodu sprawia, że IoC staje się mniej IoC? Kod frameworku nie zmienił się nic a nic
Jak zwykle radzę wyrobić sobie intuicję i się tym nie przejmować, bo nie ma sensu dywagować na temat złych pojęć i abstrakcji, które sobie ewoluowały w burzliwy sposób (polecam wiki).
W sumie jak przeglądam zagraniczne źródła to dominują bardziej precyzyjne określenia niż na angielskojęzycznej wikipedii, jedni utożsamiają framework z kontenerami IoC a drudzy rozdzielają frameworki od kontenerów IoC:
"Inversion of Control is a principle in software engineering which transfers the control of objects or portions of a program to a container or framework."
https://medium.com/@karan0361.be20/understanding-the-concept-of-dependency-injection-di-and-inversion-of-control-ioc-ae8250a7a48d
"IoC Containers are frameworks"
https://dotnettutorials.net/lesson/introduction-to-inversion-of-control/
W różnych postach takie definicje:
"the framework or container is responsible for managing the flow of control"
"In simple words, Inversion of Control is a container which is responsible for object creation and object lifecycle."
"In Spring, IOC is a Container which has 2 containers i.e Core Container and J2EE Container."
https://www.quora.com/What-is-the-inversion-of-control-in-a-spring-framework
Czyli bym się skłaniał do takiej definicji, że Inversion of control to oddanie kontroli sterowania nad wykonywaniem programu na rzecz frameworka lub KONTENERA IoC. Myślę, że to dużo bardziej zrozumiałe. Czyli w sumie tak jak Riddle napisał pisząc o frameworku lub bibliotece. Ta definicja z wikipedii taka niejasna moim zdaniem.
aleksandercherpski2 napisał(a):
W sumie jak przeglądam zagraniczne źródła to dominują bardziej precyzyjne określenia niż na angielskojęzycznej wikipedii:
To trochę jak tłumaczenie biblii. Ktoś te kilka tysięcy lat temu napisał jakiś tekst i teraz ogarnięte osoby próbują to jakoś zinterpretować. Problemem jest fakt, że niejasna definicja ma dużo różnych interpretacji.
KamilAdam napisał(a):
I teraz w przypadku 1. i 2. jest to IoC według tej definicji a w przypadku 3. - nie. Chociaż kod aplikacji się nie zmienił, za wyjatkiem tego jednego maina. Zastanawiające
Ja wiem iż to dziwny przypadek ten 3. Z drugiej stony Spring Core powstał na kolanie żeby pokazać iż da się wstrzykiwać w niepatologiczny sposób. Kto pamięta EJB wie co to patologiczne wstrzykiwanie
Nie widzę tutaj nic dziwnego.
Natomiast kwestia jest taka, że IoC to właśnie jest oddanie kawałka kontroli jakiemuś mechanizmowi IoC. Możesz go nawet samemu napisać.
W przypadku robienia tego ręcznie tego mechanizmu nie ma. Ot, i cała filozofia.
wartek01 napisał(a):
Nie widzę tutaj nic dziwnego.
Natomiast kwestia jest taka, że IoC to właśnie jest oddanie kawałka kontroli jakiemuś mechanizmowi IoC. Możesz go nawet samemu napisać.W przypadku robienia tego ręcznie tego mechanizmu nie ma. Ot, i cała filozofia.
IoC można sobie zrobić ręcznie, bez żadnego mechanizmu. Tak na prawdę wystarczy dodać polimorfizm, i już można mieć IoC.
Są oczywiście "IoC frameworks", które dodają dużo więcej mieszaniny (o czym wydaje się Ty mówisz); ale samo "IoC" jest względnie proste.
Ale to gadacie o Inversion of Control czy Dependency Injection (nie mylić z Inversion)?
Bo jedno jest w tytule, a drugie jest faktycznym tematem postów, i się pogubiłem.
Jest wiele form IoC, np. wystarczy zaimplementować wzorzec metoda szablonowa, aby mieć IoC, i nie ma to żadnego związku z żadnym wstrzykiwaniem.
Dlatego też nie bardzo widzę sens w nazywaniu czegoś kontenerem IoC, to raczej kontener DI. I tak, taki kontener jak najbardziej jest frameworkiem, bo to on woła nasz kod, a nie my jego (jak w przypadku biblioteki).
somekind napisał(a):
Jest wiele form IoC, np. wystarczy zaimplementować wzorzec metoda szablonowa, aby mieć IoC
Tylko, że jak się użyje wzorca metody szablonowej lub wzorca fabryki to już wtedy definicja IoC jest w ogóle niejasna. Bo definicja mówi o frameworku a czy wzorce są frameworkiem? No chyba nie 
To nie znaczy, że @somekind ja się z Tobą nie zgadzam, bo się zgadzam, że te wzorce są przykładami implementacji IoC tylko mi to nie pasuje do definicji IoC z wikipedii, która mówi o frameworku, więc trzebaby uznać wzorce typu wzorzec fabryki za framework Chodzi mi o to, że ta definicja IoC w wikipedii jest jakaś dziwna przez to, że pada tam słowo framework.A może kontener IoC / DI, który jest kolejną implementacją inversion of control jest frameworkiem? No też nie jest? To nie rozumiem po co w tej definicji ktoś uzył słowa "framework" O to mi chodzi. 
aleksandercherpski2 napisał(a):
somekind napisał(a):
Jest wiele form IoC, np. wystarczy zaimplementować wzorzec metoda szablonowa, aby mieć IoC
Tylko, że jak się użyje wzorca metody szablonowej lub wzorca fabryki to już wtedy definicja IoC jest w ogóle niejasna. Bo definicja mówi o frameworku a czy wzorce są frameworkiem? No chyba nie
To nie znaczy, że @somekind ja się z Tobą nie zgadzam, bo się zgadzam, że te wzorce są przykładami implementacji IoC tylko mi to nie pasuje do definicji IoC z wikipedii, która mówi o frameworku, więc trzebaby uznać wzorce typu wzorzec fabryki za framework
The way I see it:
Dla przykładu: był sobie framework do webowki - można było w nim deklaratywnie dodać route'y i kontrolery, i potem zrobić jakieś application.run() i apka działała. Ale co jak chciałeś złamać zależność na to co wołasz w kontrolerze (np. w kontrolerze chciałeś zawołać jakiś interfejs, który byłby dostarczony spoza frameworka?) Na początku się nie dało, chyba że ustawiłbyś zmienną globalną albo statica. Wyjściem na to miało być "wstrzykiwanie zależności" do tych kontrolerów, ale moim zdaniem to jest workaround. Dużo lepszym wyjściem byłoby takie zaprojektowanie frameworka który po prostu pozwalałby na dostarczenie swoich zależności tak jak się chce bez żadnego IoC. Framework byłby wtedy bardziej decoupled od aplikacji. Porównaj sobie np. Laravel i Flask. Laravel sam tworzy kontrolery, przez co nie pozwala nam łatwo osiągnąć Dependency Inversion, więc powstały rozwiązania w stylu app(User::class), który pozwala definiować jakieś instancje poza kontrollerem, a potem jest "wstrzyknąć". Flask po prostu dostaje callback, do którego możemy wsadzić wszystko, więc możemy osiągnąć Dependency Inversion (i w zasadzie każdy wzorzec inny) bez IoC. Gdyby laravel był od poczatku dobrze zaprojektowany, to mógłbyś sobie po prostu przekazać swoją zależność tak o, po prostu, jak do każdej innej funkcji czy klasy.
Na logikę - kiedy kontener IoC jest potrzebny? Tylko w otoczeniu frameworka który nie pozwala osiągnąć DI normalnymi spodobami.
aleksandercherpski2 napisał(a):
Tylko, że jak się użyje wzorca metody szablonowej lub wzorca fabryki to już wtedy definicja IoC jest w ogóle niejasna. Bo definicja mówi o frameworku a czy wzorce są frameworkiem? No chyba nie
IoC oznacza, że jakiś fragment kodu jest wywoływany z innego fragmentu kodu. Ten inny fragment kodu kontroluje przepływ naszego kodu - dlatego mówimy o odwróceniu sterowania.
Tak działa metoda szablonowa i wiele innych wzorców.
Tak działają mechanizmy takie jak delegaty i eventy.
Tak działa też spora część frameworków, jest to dla nich kluczowe, bo framework sam z siebie nic nie robi, tylko wykonuje jakiś zewnętrzny kod.
Chodzi mi o to, że ta definicja IoC w wikipedii jest jakaś dziwna przez to, że pada tam słowo framework.A może kontener IoC / DI, który jest kolejną implementacją inversion of control jest frameworkiem? No też nie jest? To nie rozumiem po co w tej definicji ktoś uzył słowa "framework" O to mi chodzi.
Moim zdaniem ta definicja nie ma żadnego sensu. Dependency Injection jest jedną z form IoC, bez sensu opierać całą definicję o jeden szczególny przypadek.
somekind napisał(a):
aleksandercherpski2 napisał(a):
Tylko, że jak się użyje wzorca metody szablonowej lub wzorca fabryki to już wtedy definicja IoC jest w ogóle niejasna. Bo definicja mówi o frameworku a czy wzorce są frameworkiem? No chyba nie
IoC oznacza, że jakiś fragment kodu jest wywoływany z innego fragmentu kodu. Ten
inny fragment kodukontroluje przepływ naszego kodu - dlatego mówimy o odwróceniu sterowania.
Tak działa metoda szablonowa i wiele innych wzorców.
Tak działają mechanizmy takie jak delegaty i eventy.
Tak działa też spora część frameworków, jest to dla nich kluczowe, bo framework sam z siebie nic nie robi, tylko wykonuje jakiś zewnętrzny kod.
Yyy... a to nie jest polimorfizm po prostu? 
(boszzz, dziękuję 
każdego dnia że nie mam takich rozkmin jak w tym wątku, ament)
Riddle napisał(a):
IoC oznacza, że jakiś fragment kodu jest wywoływany z innego fragmentu kodu. Ten
inny fragment kodukontroluje przepływ naszego kodu - dlatego mówimy o odwróceniu sterowania.
Yyy... a to nie jest polimorfizm po prostu?
Nawet lepiej - bo to jest zwykłe wywołanie procedury/funkcji. Dawniej GOTO.
aleksandercherpski2 napisał(a):
Ale czymże jest ten framework?
Tak po ludzku jest to prostu frontend dla zwykłego programisty z Indii który za pomocą kilku wajch może zmienić kilka literek w w outpucie dla tego samego inputu. A framework dlatego że ten frontend tak naprawdę służy jedynie do wywołania innych frontendów które wywołują inne frontendy...