Jaka jest różnica między wzorcami Factory i Strategy?

Czy ktoś może wyjaśnić różnicę między wzorcami fabrycznymi a strategicznymi?

Dla mnie oba wyglądają tak samo poza dodatkową klasą fabryczną (która tworzy obiekt produktu we wzorach fabrycznych)

Wzorzec fabryczny to wzorzec kreacyjny. Wzorzec strategii to wzorzec operacyjny. Innymi słowy, wzorzec fabryki jest używany do tworzenia obiektów określonego typu. Wzorzec strategii służy do wykonywania operacji (lub zestawu operacji) w określony sposób. W klasycznym przykładzie fabryka może tworzyć różne typy zwierząt: psa, kota, tygrysa, podczas gdy wzorzec strategii wykonywałby określone czynności, na przykład ruch; za pomocą strategii biegu, chodu lub skoku.

W rzeczywistości oba mogą być używane razem. Na przykład może istnieć fabryka, która tworzy obiekty biznesowe. Może używać różnych strategii opartych na nośniku trwałości. Jeśli twoje dane są przechowywane lokalnie w XML, użyje jednej strategii. Gdyby dane były zdalne w innej bazie danych, użyłaby innej.

Wzorzec strategii pozwala na polimorficzną zmianę zachowania klasy.

Wzorzec fabryki umożliwia hermetyzację tworzenia obiektów.

Gary ma świetną uwagę. Jeśli używasz zasady kodowania do abstrakcji, a nie do „konkrecji”, wtedy wiele wzorców zaczyna wyglądać jak wariacje na temat.

Aby dodać do tego, co powiedział tvanfosson, wiele wzorców wygląda tak samo, jeśli chodzi o implementację. Oznacza to, że często tworzyłeś interfejs, w którym być może wcześniej nie było go w kodzie, a następnie tworzyłeś kilka implementacji tego interfejsu. Różnica polega na ich przeznaczeniu i sposobie ich wykorzystania.

• Wzorzec fabryki (metody).

Twórz tylko konkretne wystąpienia. Różne argumenty mogą dawać różne obiekty. To zależy od logiki itp.

• Wzorzec strategii.

Hermetyzuj algorytm (kroki), aby wykonać akcję. Możesz więc zmienić strategię i użyć innego algorytmu.

Chociaż oba wyglądają na bardzo podobne, cel jest raczej inny, jednym celem jest stworzenie, drugim jest wykonanie działania.

Więc. Jeśli twoja metoda Factory jest naprawiona, możesz mieć to w następujący sposób:

 public Command getCommand( int operatingSystem ) { 
      switch( operatingSystem ) { 
           case UNIX    :
           case LINUX   : return new UnixCommand();
           case WINDOWS : return new WindowsCommand();
           case OSX     : return new OSXCommand();
       }
  }

Ale przypuśćmy, że Twoja fabryka potrzebuje bardziej zaawansowanej lub dynamicznej kreacji. Możesz dodać do metody fabrycznej strategię i zmienić ją bez konieczności ponownej kompilacji, strategia może ulec zmianie w czasie wykonywania.

Przede wszystkim należy rozróżnić między prostą fabryką a fabryką abstrakcyjną. Pierwsza to prosta fabryka, w której masz tylko jedną klasę, która działa jako fabryka do tworzenia obiektów, podczas gdy w drugiej łączysz się z interfejsem fabrycznym (który definiuje nazwy metod), a następnie wywołujesz różne fabryki, które implementują ten interfejs, mają mieć różne implementacje tej samej metody w oparciu o pewne kryteria. Na przykład mamy interfejs ButtonCreationFactory, który jest zaimplementowany w dwóch fabrykach, pierwsza WindowsButtonCreationFactory (tworzy przyciski o wyglądzie i działaniu systemu Windows), a druga LinuxButtonCreationFactory (tworzy przyciski o wyglądzie i działaniu systemu Linux). Tak więc obie te fabryki mają tę samą metodę tworzenia z różnymi implementacjami (algorytmami).

Na przykład, jeśli chcesz, aby przyciski wyglądały i działały w systemie Linux:

ButtonCreationFactory myFactory = new LinuxButtonCreationFactory();
Button button1 = myFactory.createButton(...);

lub jeśli chcesz przyciski systemu Windows

ButtonCreationFactory myFactory = new WindowsButtonCreationFactory();
Button button1 = myFactory.createButton(...);

Dokładnie w tym przypadku daje to swego rodzaju wzorzec strategii, ponieważ różnicuje algorytmy wykonywania jakiejś kreacji. Jednak różni się od niego semantycznie, ponieważ jest używany do TWORZENIA OBIEKTÓW, a nie algorytmów operacyjnych. Tak więc, w zasadzie w fabryce abstrakcyjnej masz tworzenie obiektów przy użyciu różnych strategii, co czyni je bardzo podobnymi do wzorca strategii. Jednak AbstractFactory jest twórczy, podczas gdy wzorzec Strategii działa. Jeśli chodzi o wdrażanie, wynikają one z tego samego.

Fabryka (i metoda FactoryMethod zwrócona przez fabrykę) :

1. Kreacyjny wzór
2. Na podstawie dziedziczenia
3. Fabryka zwraca Factory Method (interfejs), która z kolei zwraca Concrete Object
4. Możesz zamienić nowe Concrete Objects na interfejs, a klient (wywołujący) nie powinien być świadomy wszystkich konkretnych implementacji
5. Klient zawsze ma dostęp tylko do interfejsu, a szczegóły tworzenia obiektów można ukryć w metodzie Factory

Spójrz na ten artykuł na Wikipedii i artykuł javarevisited

Wzorzec strategii:

1. To wzorzec zachowania
2. Opiera się na delegacji
3. Zmienia wnętrzności obiektu poprzez modyfikację zachowania metody
4. Służy do przełączania między rodziną algorytmów
5. Zmienia zachowanie obiektu w czasie wykonywania

Przykład:

Możesz skonfigurować strategię rabatów dla określonej pozycji (bilet lotniczy lub przedmiot ShoppingCart). W tym przykładzie zaoferujesz 25% zniżki na przedmiot w okresie od lipca do grudnia i brak rabatu na przedmiot w okresie od czerwca do czerwca.

Powiązane posty:

Przykład wzorca strategii w świecie rzeczywistym

Wzorce projektowe: metoda Factory vs Factory vs Abstract Factory

Aby rozszerzyć to, co powiedział Oscar i w odniesieniu do jego kodu:

GetCommand to Factory, a klasy UnixCommand, WindowsCommand i OSXCommand to strategie

Wzorzec strategii, mówiąc najprościej, polega bardziej na tworzeniu zachowania w czasie wykonywania, w którym nie jesteś zainteresowany klasą implementującą. Z drugiej strony fabryka jest tworzeniem w czasie wykonywania konkretnej instancji klasy i do Ciebie należy użycie dowolnego zachowania (metody) udostępnionego przez zaimplementowany interfejs.

Nie można zrozumieć różnicy po prostu patrząc na kod lub kategoryzację. Aby poprawnie uchwycić wzorce GoF, poszukaj ich intencji:

Strategia: „Zdefiniuj rodzinę algorytmów, hermetyzuj każdy z nich i uczyń je wymiennymi. Strategia pozwala zmieniać algorytm niezależnie od klientów, którzy go używają”.

Metoda fabryczna: „Zdefiniuj interfejs do tworzenia obiektu, ale pozwól podklasom zdecydować, która klasa ma zostać utworzona. Metoda fabryki umożliwia odroczenie instancji klasy do podklas”.

A oto szczegółowe wyjaśnienie dotyczące zamiarów i różnic między tymi dwoma wzorcami: Różnica między wzorcami projektowania metody fabrycznej i strategii

Mogę dygresować z Oscarem, ponieważ jego przykład implementacji Factory jest raczej ściśle powiązany i bardzo zamknięty, nic dziwnego, że wybierasz wzorzec strategii. Implementacja Factory nie powinna zależeć od ustalonej liczby tworzonych wystąpień określonych klas, na przykład:

public Command getCommand( int operatingSystem ) {        
   return commandTable.get(operatingSystem); 
}

...

public class WindowsCommand implements Command {
    ...
    static {
        CommandTable.getInstance().registerCommand(WIN_COMMAND_ID, new WindowsCommand());
    }

}

Wydaje mi się, że najbardziej odpowiednim kryterium wyboru jednego lub drugiego są głównie terminy, których używasz do nazwania swoich klas i metod, biorąc pod uwagę, że wszyscy powinniśmy programować do interfejsów, a nie do klas, a także skupiać się na celu: naszym celem jest określenie który kod będzie wykonywany w czasie wykonywania. To powiedziawszy, możemy osiągnąć cel, używając dowolnego z obu wzorców.

Strategia i fabryka to różne cele. W strategii masz zdefiniowane podejście, używając tego wzorca możesz zamienić zachowanie (algorytmy). W przypadku Factory, istnieje wiele odmian. Ale oryginalny wzorzec z fabryki stanów GO4 pozostawia tworzenie obiektu klasie potomnej. Tutaj fabryką zastępujesz całą instancję, a nie zachowanie, które Cię interesuje. W ten sposób zastąpisz cały system, a nie algorytm.

Wzorzec fabryczny to wzorzec kreacyjny, który jest tworzony z określonymi właściwościami (zachowaniem). podczas gdy w czasie wykonywania po utworzeniu nie możesz zmienić jego właściwości (zachowania). więc jeśli potrzebujesz innych właściwości (zachowania), musisz usunąć obiekt i utworzyć nowy obiekt z wymaganymi właściwościami (zachowaniem). co nie jest gud. podczas gdy w przypadku wzorca strategii u można zmienić właściwości (zachowanie) w czasie wykonywania.