JavaRush /Blog Java /Random-PL /Wzór projektowy mostu

Wzór projektowy mostu

Opublikowano w grupie Random-PL
Cześć! Wciąż rozumiemy szeroki i bardzo przydatny temat – wzorce projektowe. Dziś porozmawiamy o Bridge'u. Podobnie jak inne wzorce, Bridge służy do rozwiązywania typowych problemów, z którymi spotyka się programista podczas projektowania architektury oprogramowania. Przyjrzyjmy się dzisiaj jego funkcjom i dowiedzmy się, jak z niego korzystać.

Jaki jest wzór mostu?

Wzorzec Most jest wzorcem konstrukcyjnym. Oznacza to, że jego głównym zadaniem jest utworzenie kompletnej struktury klas i obiektów. Bridge rozwiązuje ten problem, rozdzielając jedną lub więcej klas na osobne hierarchie – abstrakcja i implementacja . Zmiana funkcjonalności w jednej hierarchii nie pociąga za sobą zmian w innej. Wszystko wydaje się jasne, ale w rzeczywistości definicja ta brzmi bardzo szeroko i nie odpowiada na główne pytanie: „Co to jest wzór Bridge?” Myślę, że łatwiej będzie Ci to sprawdzić w praktyce. Zamodelujmy od razu klasyczny przykład wzoru Bridge. Mamy klasę abstrakcyjną Shape, która ogólnie opisuje figurę geometryczną:
  • Kształt.java

    public abstract class Shape {
       public abstract void draw();
    }

    Kiedy zdecydujemy się na dodanie kształtów trójkąta i prostokąta, będziemy dziedziczyć po klasie Shape:

  • Prostokąt.java:

    public class Rectangle extends Shape {
       @Override
       public void draw() {
           System.out.println("Drawing rectangle");
       }
    }
  • Trójkąt.java:

    public class Triangle extends Shape {
       @Override
       public void draw() {
           System.out.println("Drawing triangle");
       }
    }
Wszystko wygląda prosto, dopóki nie wprowadzimy pojęcia „koloru”. Oznacza to, że każda figura będzie miała swój własny kolor, od którego będzie zależeć funkcjonalność metody draw(). Aby mieć różne implementacje metody draw(), musimy stworzyć klasę dla każdego kształtu odpowiadającego kolorowi. Jeśli są trzy kolory, to istnieje sześć klas: TriangleBlack, TriangleGreen, TriangleRed, i . Sześć klas to nie jest aż tak dużo. Ale! Jeśli będziemy musieli dodać nowy kształt lub kolor, liczba klas będzie rosła wykładniczo. Jak wyjść z tej sytuacji? Przechowywanie kolorów w polu i wypróbowywanie opcji za pomocą warunków warunkowych nie jest najlepszym rozwiązaniem. Dobrym rozwiązaniem jest wyświetlanie kolorów w osobnym interfejsie . Zaraz powiedziane, niż zrobione: stwórzmy interfejs i trzy jego implementacje - , oraz : RectangleBlackRectangleGreenRectangleRedColorBlackColorGreenColorRedColor
  • Kolor.java:

    public interface Color {
       void fillColor();
    }
  • CzarnyKolor.java:

    public class BlackColor implements Color {
       @Override
       public void fillColor() {
           System.out.println("Filling in black color");
       }
    }
  • GreenColor.java

    public class GreenColor implements Color {
       @Override
       public void fillColor() {
           System.out.println("Filling in green color");
       }
    }
  • RedColor.java

    public class RedColor implements Color {
       @Override
       public void fillColor() {
           System.out.println("Filling in red color");
       }
    }

    Dodajmy teraz Colordo klasy pole typu Shape- jego wartość otrzymamy w konstruktorze.

  • Kształt.java:

    public abstract class Shape {
       protected Color color;
    
       public Shape(Color color) {
           this.color = color;
       }
    
       public abstract void draw();
    }

    colorBędziemy używać tej zmiennej w implementacjach Shape. Oznacza to, że kształty mogą teraz korzystać z funkcjonalności interfejsu Color.

  • Prostokąt.java

    public class Rectangle extends Shape {
    
       public Rectangle(Color color) {
           super(color);
       }
    
       @Override
       public void draw() {
           System.out.println("Drawing rectangle");
           color.fillColor();
       }
    }
Proszę bardzo! Teraz możemy produkować różne kolory i kształty geometryczne nawet w nieskończoność, zwiększając liczbę klas w postępie arytmetycznym. Pole Color colorjest pomostem łączącym dwie oddzielne hierarchie klas.

Urządzenie pomostowe: czym jest abstrakcja i implementacja

Przyjrzyjmy się diagramowi klas opisującemu wzorzec Bridge: Wprowadzenie do wzorca projektowego Bridge - 2Tutaj widać dwie niezależne struktury, które można modyfikować bez wpływu na swoją funkcjonalność. W naszym przypadku jest to:
  • Abstrakcja - zajęcia Shape;
  • RefinedAbstraction -class Triangle,;Rectangle
  • Implementator - interfejs Color;
  • ConcreteImplementor - klasy BlackColori GreenColor.RedColor
Klasa Shapereprezentuje Abstrakcję - mechanizm kontrolowania kolorowania kształtów w różnych kolorach, który deleguje Implementację do interfejsu Color. Klasy Triangleto Rectanglerzeczywiste obiekty korzystające z mechanizmu oferowanego przez klasę Shape. BlackColororaz GreenColor- RedColorkonkretne wdrożenia w branży Wdrożenia. Często nazywane są platformą.

Gdzie używany jest wzór Bridge?

Ogromną zaletą stosowania tego wzorca jest to, że można wprowadzać zmiany w funkcjonalności klas w jednej gałęzi bez naruszania logiki innej. Takie podejście pomaga również zmniejszyć łączenie klas programu. Głównym warunkiem korzystania z wzorów jest „stosowanie się do instrukcji”: nie przyklejaj ich nigdzie! Właściwie zastanówmy się, w jakich przypadkach zdecydowanie musisz użyć Bridge:
  1. Jeśli konieczne jest rozszerzenie liczby elementów w dwóch kierunkach (kształty geometryczne, kolory).

  2. Jeśli chcesz podzielić dużą klasę, która nie spełnia zasady pojedynczej odpowiedzialności, na mniejsze klasy o wąskiej funkcjonalności.

  3. Jeżeli zaistnieje ewentualna potrzeba wprowadzenia zmian w logice działania poszczególnych podmiotów w trakcie działania programu.

  4. Jeśli to konieczne, ukryj implementację przed klientami klasy (biblioteki).

Wykorzystując każdorazowo wzór trzeba pamiętać, że dodaje on do kodu dodatkowe byty – nie do końca logiczne jest stosowanie go w projekcie, w którym występuje tylko jedna figura geometryczna i jeden lub dwa możliwe kolory.

Plusy i minusy wzoru

Podobnie jak inne wzory, Most ma zarówno zalety, jak i wady. Korzyści z mostu:
  1. Poprawia skalowalność kodu - możesz dodawać funkcjonalności bez obawy, że coś zepsujesz w innej części programu.
  2. Zmniejsza liczbę podklas - sprawdza się, gdy zachodzi potrzeba rozszerzenia liczby bytów w dwóch kierunkach (np. liczba kształtów i liczba kolorów).
  3. Umożliwia odrębną pracę na dwóch niezależnych gałęziach Abstrakcji i Implementacji - może to zrobić dwóch różnych programistów, bez zagłębiania się w szczegóły kodu drugiego.
  4. Ograniczenie łączenia klas - jedynym miejscem łączenia dwóch klas jest most (pole Color color).
Wady mostu:
  1. W zależności od konkretnej sytuacji i struktury projektu jako całości, może to mieć negatywny wpływ na produktywność programu (na przykład, jeśli trzeba zainicjować więcej obiektów).
  2. Komplikuje czytelność kodu ze względu na konieczność poruszania się pomiędzy klasami.

Różnica w stosunku do wzorca strategii

Wzorzec mostu jest często mylony z innym wzorcem projektowym – strategią. Obydwa wykorzystują kompozycję (w przykładzie kształtów i kolorów użyliśmy agregacji, ale wzór Bridge może również wykorzystywać kompozycję), delegując pracę innym obiektom. Ale jest między nimi różnica i to ogromna. Wzorzec Strategii jest wzorcem behawioralnym: rozwiązuje zupełnie inne problemy. Strategia pozwala na wymienność algorytmów, podczas gdy Bridge oddziela abstrakcję od implementacji, aby umożliwić wybór pomiędzy różnymi implementacjami. Oznacza to, że Bridge, w przeciwieństwie do strategii, ma zastosowanie do całych konstrukcji lub struktur hierarchicznych. Wzór Bridge może być dobrą bronią w arsenale dewelopera, najważniejsze jest znalezienie tych sytuacji, w których warto go zastosować lub zastosować jakiś inny wzór. Jeśli nie znasz jeszcze innych szablonów, przeczytaj te materiały:
Komentarze
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION