Jaka jest różnica mięczy Bridge a Strategy?

0

Czytam sobie o różnych wzorcach i utknąłem. Czy ktoś może mi wytłumaczyć jaka jest różnica między Bridge a Strategy? Kiedy i dlaczego używać którego? Obydwa w mojej ocenie wyglądają strasznie podobnie i można by je używać wymiennie.

0

Różnią się zastosowaniem.

Oba wzorce wystawiają interfejs dla jakiej operacji.

  • Bridge rozdziela implementację od abstrakcji. O Bridge mówimy, gdy chcemy ukryć szczegóły związane z implementacją.
  • Strategy pozwala na posiadanie kilku algorytmów wykonania. O Strategy mówimy, gdy podczas wykonania programu implementacja operacji może ulec zmianie. Przykładowo, czasami dane będą zapisywane jako pliki xml, a czasami jako jsony, w czasie wykonania może się to nagle zmienić, ale interfejs ma pozostać ten sam.
1

To zupełnie dwa różne wzorce. Bridge to ucieleśnienie composition over inheritance, służy do oddzielenia implementacji od interfejsu i to wzorzec strukturalny. Strategy to wzorzec behawioralny i słuzy do enkapsulacji rodziny algorytmów, taki functional programming w obiektowym świecie.

0
[TestowyJanusz napisał(a)]:

służy do oddzielenia implementacji od interfejsu

No ale właśnie, czy sama idea interfejsu nie daje tego efektu, ze mamy oddzielnie interface i oddzielnie implementującą go klasę. Więc po co jeszcze ten wzorzec?

0
Biały Programista napisał(a):
[TestowyJanusz napisał(a)]:

służy do oddzielenia implementacji od interfejsu

No ale właśnie, czy sama idea interfejsu nie daje tego efektu, ze mamy oddzielnie interface i oddzielnie implementującą go klasę. Więc po co jeszcze ten wzorzec?

Bridge pozwala rozdzielić hierarchię dziedziczenia gdy problem da się podzielić na kilka niezależnych cech. Zamiast klasy dla każdej możliwej kombinacji cech możesz mieć klasę, która zawiera klasy opisujące cechy.

https://sourcemaking.com/design_patterns/bridge

0

Pomyśl o strategii w kontekście problemów konkretnych algorytmów. Na przykład masz program do sortowania liczb.
Możesz mieć wtedy coś takiego:

abstract class Sort
{
  public abstract List<int> Sort(List<int> input);
}

//i dalej poszczególne klasy:
class BubbleSort: Sort
{
  public override List<int> Sort(List<int> input)
  {
    //sortowanie bąbelkowe
  }
}

class InsertSort: Sort
{
  public override List<int> Sort(List<int> input)
  {
    //sortowanie przez wstawianie
  }

}

Itd. I teraz w aplikacji możesz mieć sortowanie w zależności od wybranej opcji przez użytkownika, np:

Sort sorter = GetSortClass(); //tutaj w jakiś magiczny sposób zwraca Ci konkretny obiekt
List<int> sorted = sorter.Sort(items);

Tak działa startegia. Masz kilka różnych algorytmów do wykonania tego samego zadania.
Natomiast Bridge robi coś zupełnie innego. Oddziela abstrakcję od implementacji. Dzięki czemu możesz modyfikować te dwa elementy niezależnie. W C++ idealnym przykładem byłoby użycie idiomu pImpl.

To tak jakbyś miał dwa zestawy klas. Np.
(pomijam parametry)

class Window
{
  public void DrawText();
  public void DrawLine();
}

class Button: Window
{
  public void Click();
}

I drugi zestaw:

class WindowImpl
{
  public void DrawTextOnDevice();
  public void DrawLineOnDevice();
}

class ButtomImpl: WindowImpl
{
  public void DoInterrupt();
}

I teraz bridgem będzie np. przejście pomiędzy Window i WindowImpl:

class Window
{
  WindowImpl impl = GetWindowImpl(); //to może być np. fabryka abstrakcyjna

  public void DrawText()
  {
    impl.DrawTextOnDevice();
  }
}

Dzięki temu masz całkowicie oddzieloną implementację od abstrakcji. Dużo bardziej niż w przypadku strategii. Tutaj masz dwa zestawy klas, gdzie jeden zestaw odpowiada za abstrakcję, a drugi za implementację.

0

Zapoznaj się z następującymi materiałami:

  1. Dla wzorca "Bridge" -> https://sourcemaking.com/design_patterns/bridge
  2. Dla wzorca strategia -> http://www.javadeveloper.pl/wzorzec-projektowy-strategia

1 użytkowników online, w tym zalogowanych: 0, gości: 1