Metodę szablonów i wzory szablonów strategii

Question

Jest to prawdopodobnie pytanie początkujących, ponieważ jestem nowy w projektowaniu wzorców, ale patrzyłem na metodę szablonów i strategię DP i wydają się bardzo podobne. Potrafię czytać definicje, badać UML i sprawdzać przykłady kodu, ale wydaje mi się, że wzorzec Strategii właśnie używa wzorca Metody Szablonu, ale po prostu przekazujesz go i obiekt (czyli kompozycję).

I w tym przypadku wydaje się, że metoda szablonowa jest podstawowym dziedziczeniem OO.

Czy brakuje mi kluczowego aspektu różnic? Czy brakuje mi czegoś o metodzie szablonów, która sprawia, że ​​jest to po prostu podstawowe dziedziczenie?

Uwaga: Istnieje wcześniejszy wpis na ten temat (672083), ale bardziej na temat tego, kiedy go używać, który pomaga mi uzyskać trochę więcej, ale chcę, aby moje myśli na temat samych wzorów.

Answer 1

To wszystko sprowadza się do semantyki. Wzorzec strategii umożliwia przekazanie określonego algorytmu/procedury (strategii) do innego obiektu, który go użyje. Metoda szablonów pozwala na zastąpienie określonych aspektów algorytmu, zachowując jednocześnie pewne jego aspekty (zachowując kolejność na tym samym poziomie i zawsze robiąc rzeczy, które są zawsze wykonywane na początku i na końcu, np. "Szablon") dziedziczenie jest sposobem modelowania relacji "IS-A" w modelach danych.

Oczywiście, metody szablonów najłatwiej są zaimplementowane przy użyciu dziedziczenia (chociaż równie dobrze można użyć kompozycji, zwłaszcza gdy masz już funktory), a wzorce strategii są często również szablonowymi metodami, ale tam, gdzie składnia jest podobna, znaczenia są bardzo różne .

Answer 2

Wzór Strategy konstrukcja
zapewnia sposób wymiany algorytm obiektu dynamicznie w czasie wykonywania
(poprzez kompozycji obiektu).

Na przykład, obliczanie cen w systemie przetwarzania zamówień.
Aby obliczyć ceny na różne sposoby, można zastosować różne algorytmy wyceny , aby wybrać algorytm do użycia (wstrzyknięty) i wymienić go dynamicznie w czasie wykonywania.

Template Method wzornictwo
zapewnia sposób zdefiniowanie niektórych części zachowaniem klasy statycznie w czasie kompilacji
(przez podklasy).

Na przykład projektowanie aplikacji wielokrotnego użytku (frameworków).
Aplikacja implementuje wspólne (niezmienne) części zachowania , dzięki czemu użytkownicy aplikacji mogą pisać podklasy, aby zmienić definicję części na inną zgodnie ze swoimi potrzebami. Jednak autorzy podklas nie powinni mieć możliwości zmiany niezmiennych części zachowania ani struktury zachowania (struktura niezmiennych i wariantowych części).