JavaRush /Java Blog /Random-KO /교량 디자인 패턴

교량 디자인 패턴

Random-KO 그룹에 게시되었습니다
안녕하세요! 우리는 디자인 패턴이라는 광범위하고 매우 유용한 주제를 계속해서 이해하고 있습니다. 오늘은 Bridge에 대해 이야기해보겠습니다. 다른 패턴과 마찬가지로 Bridge는 개발자가 소프트웨어 아키텍처를 설계할 때 직면하는 일반적인 문제를 해결하는 역할을 합니다. 오늘은 그 기능을 연구하고 어떻게 사용하는지 알아봅시다.

브리지 패턴이란 무엇입니까?

브리지 패턴은 구조적 디자인 패턴입니다. 즉, 주요 임무는 클래스와 객체의 완전한 구조를 만드는 것입니다. Bridge는 하나 이상의 클래스를 별도의 계층 구조( 추상화구현) 로 분리하여 이 문제를 해결합니다 . 한 계층의 기능 변경이 다른 계층의 변경을 수반하지 않습니다. 모든 것이 명확해 보이지만 실제로 이 정의는 매우 광범위하게 들리며 "브리지 패턴이란 무엇입니까?"라는 주요 질문에 답하지 않습니다. 이것이 실제로 알아내는 것이 더 쉬울 것이라고 생각합니다. 브리지 패턴의 전형적인 예를 즉시 모델링해 보겠습니다. Shape일반적으로 기하학적 도형을 설명하는 추상 클래스가 있습니다 .
  • Shape.java

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

    삼각형과 직사각형 모양을 추가하기로 결정하면 다음 클래스에서 상속됩니다 Shape.

  • 직사각형.java:

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

    public class Triangle extends Shape {
       @Override
       public void draw() {
           System.out.println("Drawing triangle");
       }
    }
"색상"이라는 개념을 도입하기 전까지는 모든 것이 단순해 보입니다. 즉, 각 그림은 고유한 색상을 가지며, 이에 따라 메소드의 기능이 달라집니다 draw(). 메서드를 다르게 구현하려면 draw()색상에 해당하는 각 모양에 대한 클래스를 만들어야 합니다. 세 가지 색상이 있는 경우 TriangleBlack, TriangleGreen, TriangleRed, RectangleBlack및 의 6개 클래스 RectangleGreen가 있습니다 RectangleRed. 6개 클래스는 그다지 큰 문제가 아닙니다. 하지만! 새로운 모양이나 색상을 추가해야 하면 클래스 수가 기하급수적으로 늘어납니다. 이 상황에서 벗어나는 방법은 무엇입니까? 필드에 색상을 저장하고 조건을 통해 옵션을 시도하는 것은 최선의 해결책이 아닙니다. 좋은 해결책은 별도의 인터페이스에 색상을 표시하는 것 입니다 . 말하자마자 완료되었습니다. 인터페이스 Color와 해당 구현 중 세 가지( BlackColor, GreenColor및 ) 를 만들어 보겠습니다 RedColor.
  • Color.java:

    public interface Color {
       void fillColor();
    }
  • BlackColor.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");
       }
    }

    Color이제 클래스에 유형 필드를 추가해 보겠습니다 Shape. 생성자에서 해당 값을 받게 됩니다.

  • 모양.java:

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

    우리는 구현에서 변수를 color사용할 것입니다 Shape. 이는 이제 모양이 인터페이스의 기능을 사용할 수 있음을 의미합니다 Color.

  • Rectangle.java

    public class Rectangle extends Shape {
    
       public Rectangle(Color color) {
           super(color);
       }
    
       @Override
       public void draw() {
           System.out.println("Drawing rectangle");
           color.fillColor();
       }
    }
여기요! 이제 우리는 무한히 다양한 색상과 기하학적 모양을 생성하여 산술 수열의 클래스 수를 늘릴 수 있습니다. 필드는 Color color두 개의 개별 클래스 계층을 상호 연결하는 브리지입니다.

브리지 장치: 추상화 및 구현이란 무엇입니까?

브리지 패턴을 설명하는 클래스 다이어그램을 살펴보겠습니다. 브리지 디자인 패턴 소개 - 2여기서는 서로의 기능에 영향을 주지 않고 수정할 수 있는 두 개의 독립적인 구조를 볼 수 있습니다. 우리의 경우는 다음과 같습니다.
  • 추상화 - 클래스 Shape;
  • RefinedAbstraction - 클래스 Triangle, Rectangle;
  • 구현자 - 인터페이스 Color;
  • ConcreteImplementor - 클래스 BlackColorGreenColor.RedColor
클래스는 Shape구현을 인터페이스에 위임하는 다양한 색상의 모양 색상을 제어하는 ​​메커니즘인 추상화를 나타냅니다 Color. 클래스는 클래스가 제공하는 메커니즘을 사용하는 실제 객체 Triangle입니다 . 및 - 구현 분기의 특정 구현입니다. 흔히 플랫폼이라고 합니다. RectangleShapeBlackColorGreenColorRedColor

브리지 패턴은 어디에 사용되나요?

이 패턴을 사용하면 다른 브랜치의 논리를 깨지 않고도 한 브랜치에 있는 클래스의 기능을 변경할 수 있다는 큰 장점이 있습니다. 이 접근 방식은 프로그램 클래스의 결합을 줄이는 데에도 도움이 됩니다. 패턴을 사용하는 주요 조건은 "지침을 따르는 것"입니다. 어디에도 붙이지 마십시오! 실제로 어떤 경우에 Bridge를 사용해야 하는지 알아봅시다.
  1. 두 방향(기하학적 모양, 색상)으로 개체 수를 확장해야 하는 경우.

  2. 단일 책임 원칙을 충족하지 않는 대규모 클래스를 좁은 프로필 기능을 갖춘 소규모 클래스로 나누려는 경우.

  3. 프로그램이 실행되는 동안 특정 엔터티의 작동 논리를 변경해야 할 가능성이 있는 경우.

  4. 필요한 경우 클래스(라이브러리) 클라이언트에서 구현을 숨깁니다.

매번 패턴을 사용할 때 코드에 추가 엔터티를 추가한다는 점을 기억해야 합니다. 하나의 기하학적 도형과 하나 또는 두 개의 가능한 색상만 있는 프로젝트에서 패턴을 사용하는 것은 전적으로 논리적이지 않습니다.

패턴의 장점과 단점

다른 패턴과 마찬가지로 Bridge에도 장점과 단점이 있습니다. 브리지의 장점:
  1. 코드 확장성 향상 - 프로그램의 다른 부분에서 문제가 발생할 염려 없이 기능을 추가할 수 있습니다.
  2. 하위 클래스 수 감소 - 엔터티 수를 두 방향(예: 모양 수 및 색상 수)으로 확장해야 할 때 작동합니다.
  3. 추상화와 구현의 두 가지 독립적인 분기에서 개별적으로 작업할 수 있습니다. 이는 서로의 코드를 자세히 조사하지 않고도 두 명의 다른 개발자가 수행할 수 있습니다.
  4. 클래스 결합 감소 - 두 클래스가 연결되는 유일한 장소는 브리지(필드 Color color)입니다.
브리지의 단점:
  1. 특정 상황과 프로젝트 전체의 구조에 따라 프로그램 생산성에 부정적인 영향이 있을 수 있습니다(예: 더 많은 개체를 초기화해야 하는 경우).
  2. 클래스 간을 탐색해야 하기 때문에 코드 가독성이 복잡해집니다.

Strategy 패턴과의 차이점

브리지 패턴은 종종 다른 디자인 패턴인 전략과 혼동됩니다. 둘 다 작업을 다른 개체에 위임하여 구성을 사용합니다(모양 및 색상 예제에서는 집계를 사용했지만 Bridge 패턴도 구성을 사용할 수 있음). 그러나 그들 사이에는 차이가 있고 그것은 엄청납니다. 전략 패턴은 행동 패턴입니다. 완전히 다른 문제를 해결합니다. 전략은 알고리즘의 상호 교환성을 허용하는 반면 Bridge는 구현에서 추상화를 분리하여 다양한 구현 중에서 선택할 수 있도록 합니다. 즉, Bridge는 Strategy와 달리 전체 구성이나 계층 구조에 적용됩니다. Bridge 패턴은 개발자의 무기고에서 좋은 무기가 될 수 있으며, 가장 중요한 것은 이를 사용할 가치가 있는 상황을 찾거나 다른 패턴을 사용하는 것입니다. 아직 다른 템플릿에 익숙하지 않다면 다음 자료를 읽어보세요.
코멘트
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION