Widzę wiele frameworków IoC dla .Net i Java. Czy ktoś wie, dlaczego nie ma równoważnych ram dla Smalltalk. To jest bardziej filozoficzne pytanie niż cokolwiek innego. Zastanawiam się, czy w sposobie Smalltalk jest coś takiego, co wyklucza konieczność posiadania ram IoC.Smalltalk i IoC
MVC został wynaleziony na Smalltalk i jest prawdopodobnie oryginalnym ramem Inversion of Control. Chociaż jest nieco bardziej lekki niż jego odpowiedniki w języku Java, ma podstawowe pojęcia dotyczące modelu przechowującego dane, widok renderujący dane w odpowiedzi na zdarzenia propagowane z kontrolera.
Mniej niepotrzebnie, Java jest rzeczywiście potrzebna wiele wsparcia ramowego, aby zrobić aplikację internetową bez nadmiernej ilości kodu standardowego. Smalltalk obsługuje idiomy programowania, takie jak continuations, które pozwalają autorowi udawać, że tak naprawdę nie piszą kodu sterowanego zdarzeniami. Seaside działa w ten sposób, dając korzyści z IoC z nieco bardziej elastycznym paradygmatem rozwoju.
EDYCJA: MVC to framework dla interfejsów użytkownika w Smalltalk (prawdopodobnie nie jest to tak naprawdę framework jako taki, ale biblioteka klas ma wbudowane wsparcie dla niego). Ma odwrócenie właściwości kontrolnej, ponieważ widok i model reagują na zdarzenia wywołane przez kontroler - nie dzwoń do nas, zadzwonimy do ciebie własności. Inversion of Control to wzorzec projektowy w ramach, który jest używany do zmniejszenia zapotrzebowania na obszerny zestaw znaków w aplikacjach java. W niektórych definicjach szkieletu aplikacji, Inversion of Control jest główną właściwością, która jest postrzegana jako odróżniająca framework od biblioteki.
Nigel: Miałem świadomość, że MVC pochodzi z Smalltalk. To, co mnie wprawia w zakłopotanie, to fakt, że struktura IoC, taka jak Castle, zawiera ramy MVC (MonoRail) i framework IoC (Windsor), które sugerują, że są różne? – mchean
Problem językowy: Delegaci/Zamknięcia/Oddzwonienia/Obsługa zdarzeń jest tak łatwa na małej platformie, aby zostać niezauważonym. Ponieważ trudniej jest uzyskać IoC na innych platformach, a także dlatego, że wymaga on implementacji kodu rusztowania (szkieletu) i konsekwentnie, można oczekiwać, że taki kod na rusztowaniu będzie wymagany w Smalltalk. Nie ma takiej potrzeby. Ponieważ to łatwe. –
Funkcje są pierwszorzędnymi obywatelami w smalltalk, więc łatwo jest mieć IoC bez frameworka.
Myślę, że wzór IOC lub Dependency Injection rozwiązuje problem, który tak naprawdę nie istnieje w środowisku Smalltalk. Smalltalk jest nietkniętym dynamicznym językiem i wykorzystuje przekazywanie wiadomości do komunikacji. To sprawia, że obiekty luźno związane z naturą na poziomie języka. Każdy obiekt może wysłać wiadomość do innego obiektu bez względu na typ, o ile może przetworzyć wiadomość. Tak więc, jak można się domyślić, zmiana zależności w dowolnym momencie jest stosunkowo łatwa i naturalna. Po prostu musisz zdecydować, gdzie, kiedy i jak chcesz zmienić zależność.
"rozwiązuje problem, który tak naprawdę nie istnieje w Smalltalk" - * tak * Poza tym programiści Smalltalk są uprzejmi dla kociąt: http://www.flickr.com/photos/dafydd_ll_rees/4528702680/ – daf
Kilka możliwych powodów. Jedną z nich jest to, że nie zadaliśmy sobie trudu, aby użyć kwalifikatora "IoC", który jest w istocie zbędny - ponieważ wywołanie czegoś w strukturze oznacza inwersję przepływu sterowania.
Innym jest to, że język Smalltalk zapewnia bezpośrednie wsparcie dla przepływów "IoC" - w postaci zamknięć. Jednym z rezultatów programowania z zamknięciami jest to, że przepływ kontroli, jaki znajduje się w ramach, nie wydaje się tak odmienny, aby wywoływać poczucie "odwrócenia" od "normalnego" przepływu; raczej, z zamknięciami, przepływ kontroli zmienia się pomiędzy tymi dwiema perspektywami przez cały czas i wszędzie. Nawet w pojedynczych stwierdzeniach.
Trzecim powodem może być to, że nawet bez zamknięć opisywana "inwersja kontroli" nie jest jednoznacznie związana z ramami - te same przepływy występują w większości form kodu, które dotyczą operacji we/wy.
Po czwarte, Smalltalkers prawdopodobnie używają tego rodzaju przepływów nawet bardziej niż inne, ponieważ opieramy się bardziej na pojęciach obiektów i wiadomości przesyłanych między nimi niż na koncepcjach struktur i wywoływaniu funkcji członka. W przypadku nieobecności zamknięć te dwa widoki są równoważne i wymienne, ale dodanie zamknięć zmienia wynik - jednym z efektów jest poczucie przepływu kontrolnego w użyciu.
Wreszcie, można by nawet pomyśleć o opisaniu stylu sterowania REPL jako "prostszego", ale "odwróconego" poczucia "normalnego" przepływu, normalnego w tym sensie, że używa się go prawie wszędzie.
Podsumowując, istnieją takie same rodzaje ram dla Smalltalk. Opisujemy je trochę inaczej. Różnica polega, przynajmniej w części, z powodu obecności i wykorzystania zamknięć w Smalltalk, których wiele innych środowisk jeszcze nie zapewnia - - zwłaszcza w językach C++, C# i Java.
W Javie zależność jest tworzony, gdy piszesz coś podobnego
MyClass32 temp = this.theThing();
Teraz twój kod ZALEŻY od klasy MyClass32 . Twój kod nie zadziała bez niego. Każda zmiana w tej klasie może spowodować, że twój kod będzie nieskompilowany, co wymaga dużej liczby dodatkowych zmian w kodzie, co może wymagać dalszych zmian kodu w klasie zależnych od twojego. Mnóstwo dodatkowej pracy.
W Smalltalk napiszesz: temp: = self theThing;
Twój kod będzie działał bez względu na to, co zwróci przez #getTheThing. Twój kod nie jest zależny od klasy w klasie MyClass32. Twoja jedyna zależność od polega na tym, że "temp" musi rozumieć, jakie wiadomości mu przesyłasz.
W pewnym sensie celem Dependency Injection Frameworks jest stworzenie statycznie napisanego języka podobnie jak Java działa bardziej jak typowo dymano.
To powiedziawszy, istnieje WZORZECZ W DESIGNIE Często włączyłem w Smalltalk: Utwórz metodę klasy taką jak MyClass, która zwraca KATALOG. Nie musi mieć NAZWISKO "MyCLass". Może to być jedna z kilku klas , zwracająca inną klasę w nocy. Ten wzorzec występuje w Smalltalk MVC, , gdzie klasy widoku mają metodę #defaultControllerClass, , która jest zazwyczaj ponownie definiowana przez podklasy.
Świetne pytanie! – daf