Dlaczego wzorzec wstrzykiwania zależności nie został uwzględniony w grupie czterech osób ? Czy wcześniejsze, szeroko rozpowszechnione automatyczne testy GOF? Czy wstrzykiwanie zależności jest obecnie uważane za podstawowy wzór?
design-patterns
Tom Squires
źródło
źródło
Odpowiedzi:
Byłem redaktorem magazynu Software Development, kiedy ukazała się książka Gang of Four, i mogę z całkowitą pewnością stwierdzić, że testy jednostkowe nie były powszechną praktyką w 1994 r., Kiedy to po raz pierwszy opublikowano wzorce projektowe .
W 1994 r. C ++ był najczęściej używanym językiem obiektowym i większość programujących go osób pochodziła z języka C. Jedną z rzeczy „myślenia w obiektach”, których ludzie po prostu nie mieli, jest pomysł setek lub tysięcy punktów wejścia do twojego programu. Myślałeś o
main(). Jeśli pracowałeś nad dużym projektem, możesz mieć (zwykle dość skomplikowany) plik makefile, aby utworzyć program oparty na modułach. Ale „testowanie jednostkowe”? Uruchamianie procesu, budowanie niezbędnego kontekstu pamięci, wykonywanie go i rozrywanie go według metody ? To było bardzo radykalne.Java uczyniła programowanie z wieloma punktami wejścia bardziej oczywistym. Do czasu boomu Dot-Com testy jednostkowe były dobrze znaną techniką, ale tak naprawdę to JUnit (około 2001?) Spowodował, że zapaliło się i stało się powszechną praktyką.
Chociaż strategia i ogólna koncepcja programowania interfejsu były częścią GoF i zeitgeist z połowy lat 90., pomysł iniekcji przyszedł dość późno na imprezę (około '03 -05?). Szczerze mówiąc, moje siwe włosy są nadal dość wątpliwe w odniesieniu do tego aspektu DI („Zejdź z trawnika, cholerne pliki konfiguracyjne!”).
źródło
Nazwali to Strategią .
Wydaje się, że ich strategia ma wszystkie cechy wstrzykiwania zależności bez nazwy o złożonym brzmieniu.
źródło
Myślę, że Wstrzykiwanie zależności jest bardziej odpowiednie przy rozdzielaniu implementacji na poziomach. Kolejnym obszarem, w którym myślimy o wstrzykiwaniu zależności, są testy jednostkowe. A twoja sugestia przed datą wydaje się poprawna. Jeśli gang miałby zbierać i segregować wzorce w 2012 roku, na pewno będzie tam zastrzyk zależności.
Strategia może pojawiać się w dyskusjach, ale strategia nie mówi o zastrzyku zależności. Ale gdy używasz wzorca strategii w jednym projekcie lub dll (wszystkie klasy i interfejsy pozostają w jednym projekcie), wydaje się, że robimy wstrzykiwanie zależności. W rzeczywistości nie jesteśmy.
Teraz, jeśli klasy i interfejsy wymienione we wzorcu strategii zostaną rozdzielone w różnych projektach lub warstwach, wówczas będziemy musieli zastosować techniki wstrzykiwania zależności. Możemy użyć plików konfiguracyjnych jedności (jednak nie jest możliwa zmiana środowiska wykonawczego). Ale wzorzec strategii nie mówi, jak wstrzyknąć zależność.
Jeśli istnieje wzorzec bardzo podobny do wstrzykiwania zależności, to jest to wzorzec metody abstrakcyjnej fabryki. Ten wzorzec może być użyty wewnątrz wzorca strategii do wstrzyknięcia zależności.
źródło
odpowiedź Strategia jest w 100% poprawna. Zagłosowałem, ale mogę komentować.
„Strategia pozwala algorytmowi zmieniać się niezależnie od klientów, którzy go używają. [1] Strategia jest jednym z wzorców zawartych w wpływowej książce Design Patterns autorstwa Gamma i in., Która spopularyzowała koncepcję używania wzorców do opisywania projektowania oprogramowania”.
Wzór projektowy nie zależy od jego użycia. Wstrzykiwanie zależności jest realizowane przy użyciu wzorca strategii. Gdybyśmy nazwali każdy wzorzec na podstawie przypadku użycia, musielibyśmy zmienić nazwę wielu wzorców.
Wzorzec repozytorium nie jest nowym wzorcem, jest Wzorzec szablonu.
„W metodzie szablonowej tego wzorca projektowego jeden lub więcej kroków algorytmu można zastąpić podklasami, aby umożliwić różne zachowania, zapewniając jednocześnie, że algorytm nadrzędny jest nadal przestrzegany”.
Często wzory są łączone i nazywane wieloma wzorami, takimi jak wzór MVC.
GOF nie miał interfejsów używanych klas Pure Abstract, a także skorzystał ze zdolności C ++ do dziedziczenia z więcej niż jednej klasy.
źródło