TIL
  • Contents
  • Book
    • 도메인 주도 설계
      • 1. 동작하는 도메인 모델 만들기
    • 오브젝트
      • 데이터 중심 설계
      • 책임 중심 설계
      • 책임 할당을 위한 GRASP 패턴
      • 메시지와 인터페이스
      • 객체 분해
    • Effective Java
      • Item 7 - 다 쓴 객체 참조를 해제하라
      • Item 7 발표 내용
      • Item 13 - clone 재정의는 주의해서 진행하라
      • Item 13 발표 내용
      • Item 16 - public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
      • Item 16 발표 내용
      • Item 26 - 로 타입은 사용하지 말라
      • Item 28 - 배열보다는 리스트를 사용하라
      • Item 28 발표 내용
      • Item 29 - 이왕이면 제네릭 타입으로 만들라
      • Item 30 - 이왕이면 제네릭 메서드로 만들라
      • Item 31 - 한정적 와일드 카드를 사용해 API 유연성을 높이라
      • Item 35 - ordinal 메서드 대신 인스턴스 필드를 사용하라
      • Item 37 - ordinal 인덱싱 대신 EnumMap을 사용하라
      • Item 37 발표 내용
      • Item 43 - 람다보다는 메서드 참조를 사용하라
      • Item 43 발표 정리
      • Item 56 - 공개된 API 요소에는 항상 문서화 주석을 작성하라
      • Item 56 발표 정리
      • Item 62 - 다른 타입이 적절하다면 문자열 사용을 피하라
      • Item 62 발표 정리
      • Item 73 - 추상화 수준에 맞는 예외를 던지라
      • Item 83 - 지연 초기화는 신중히 사용하라
      • Item 83 발표 내용
      • Item 89 - 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라
      • Item 89 발표 내용
    • 개발자를 위한 SQL 튜닝
      • SQL 쿼리 실습을 위한 DB 서버 구축
      • 인덱스 튜닝
      • 인덱스 스캔 튜닝
      • 인덱스 스캔 튜닝 실습
      • 인덱스 패스트 풀 스캔
      • 테이블 풀 스캔 튜닝
      • 조인 튜닝
      • 중첩 루프 조인 튜닝
      • 중첩 루프 조인 튜닝 실습
      • 해시 조인 튜닝
      • 해시 조인 튜닝 실습
      • 세미 조인 튜닝
      • 세미 조인 튜닝 실습
      • 아우터 조인
      • 함수 튜닝
      • 부분 범위 처리 튜닝
      • 파티셔닝 튜닝
      • 파티션 인덱스 튜닝
      • 병렬 처리 튜닝
  • Java
    • Design Pattern
      • Intro
      • Types of Design Patterns
      • Creational
        • Builder Pattern
        • Singleton Pattern
        • Prototype Pattern
        • Factory Pattern
        • Abstract Factory Pattern
      • Structural
        • Adapter Pattern
        • Bridge Pattern
        • Composite Pattern
        • Decorator Pattern
        • Facade Pattern
        • Flyweight Pattern
        • Proxy Pattern
      • Behavioural
        • Chain of Responsibility Pattern
        • Command Pattern
        • Interpreter Pattern
        • Iterator Pattern
        • Mediator Pattern
        • Memento Pattern
        • Observer Pattern
        • State Pattern
        • Strategy Pattern
        • Template Method Pattern
        • Visitor Pattern
    • Java
      • Cracking the Coding Interview
      • TDD, Clean Code with Java 11기
        • 자동차 레이싱
        • 로또
        • 사다리 타기
        • 볼링 게임 점수판
    • 궁금증
      • 자바 8 버전의 인터페이스와 추상클래스
      • 자바의 제네릭은 어떻게 이전 버전과 호환되는 걸까?
      • 스프링 MVC 기본 구조
      • 마샬링과 직렬화
      • 인터뷰 질문 모음
      • Code Coverage
  • Database
    • Database
      • SQL 레벨업
      • DB 스터디
        • DBMS
          • MySQL
        • INDEX
        • Join(Nested Loop, Hash)
        • Join(Semi, Outer)
        • Partial Range Processing
        • Function
        • Partitioning
        • Parallel Processing
  • Network
  • Architecture
    • Issue
      • Git Push Error
      • SonarLint Warning - assertThatExceptionOfType()
  • Infra
  • Spring
    • Spring JPA
      • 1. 데이터 모델링 및 연관관계 설정
      • 2. 최적화 내용
      • 3. Spring-Data-Jpa
      • 4. Query DSL
    • Spring Security
      • Intro
    • Spring Batch
      • 배치용 디비 설치
      • 배치 데이터 분석하기
      • 배치 프로세스 구상하기 및 성능 차이 확인하기
  • Issue
  • Tistory
    • Tistory Blog
  • Design High Performing Architectures
  • Design Resilient Architectures
  • Design Secure Applications And Architectures
  • Design Cost-Optimized Architectures
Powered by GitBook
On this page
  • Intro
  • 문제 상황
  • 추상화 및 구현
  • 적용가능한 상황
  • 구현 방법
  • 장점과 단점

Was this helpful?

  1. Java
  2. Design Pattern
  3. Structural

Bridge Pattern

Structural Pattern

PreviousAdapter PatternNextComposite Pattern

Last updated 3 years ago

Was this helpful?

Intro

  • 큰 클래스 또는 밀접하게 관련된 클래스 집합을 서로 독립적으로 개발할 수 있는 추상화 및 구현이라는 두 개의 개별 계층으로 분할 할 수 있는 구조적 디자인 패턴이다.

문제 상황

  • 상속 관계의 코드에서 흔히 발생 할 수 있는 문제점은 하나의 카테고리로 구분하여 개발했지만, 추후 지속적인 확장으로 잠재적인 카테고리가 발생하는 경우

  • Bridge Pattern 은 상속 관계를 개체 구성으로 전환하여 문제를 해결하는 방식이다.

추상화 및 구현

  • 추상화는 높은 수준의 제어 로직을 제공하고, 저수준 작업을 수행하기 위해 구현 객체에 의존하게 된다.

  • 구현은 모든 구체적인 구현에 대한 공통 인터페이스를 선언한다. 추상화는 여기에 선언된 메서드를 통해서만 구현 개체와 통신할 수 있다.

  • 구체적인 구현에는 플랫폼 별 코드가 포함되어 있다.

  • 세련된 추상화는 제어 로직의 변형을 제공한다. 부모와 마찬가지로 일반 구현 인터페이스를 통해 다른 구현으로 작업한다.

  • 일반적으로 클라이언트는 추상화 객체가 제공하는 인터페이스에만 관심을 갖는다. 결국 추상화 개체를 구현 개체 중 하나와 연결하는 것은 클라이언트의 작업이다.

적용가능한 상황

  • 일부 기능에 대해서 다양한 변형이 존재하는 모놀리틱 클래스를 확장성 있게 나누고 구성하려는 경우 Bridge 패턴을 사용할 수 있다.

  • 모놀리틱 클래스가 커질수록 작동 방식을 파악하기 어려워지고 변경하는데 더 오래 걸리게 된다.

  • 기능 변형 중에 하나를 변경하기 위해서 전체 클래스를 변경해야 하는 경우

  • 런타임에 구현 클래스로 전환되어 실행할 수 있어야 하는 경우 Bridge 패턴을 사용한다.

    • 선택사항이지만 Bridge 패턴을 사용하면 추상화 내부의 구현 개체를 바꿀 수 있다.

구현 방법

  1. 클라이언트에 필요한 작업을 확인하고 기본 추상화 클래스에서 정의한다.

  2. 모든 플랫폼에서 사용 가능한 작업을 결정한다. 일반 구현 인터페이스에서 추상화에 필요한 것을 선언한다.

  3. 도메인의 모든 플랫폼에 대해 구체적인 구현 클래스를 생성하되 모두 구현 인터페이스를 따르는지 확인

  4. 추상화 클래스 내에 구현 유형에 대한 참조 필드를 추가 추상화는 대부분의 작업을 해당 필드에서 참조되는 구현 개체에 위임한다.

  5. 고수준 로직의 여러 변형이 있는 경우 기본 추상화 클래스를 확장하여 각 변형에 대해 정제된 추상화를 만든다.

  6. 클라이언트 코드는 구현 개체를 추상화의 생성자에 전달하여 하나를 다른 개체와 연결해야 한다. 그 후에 클라이언트는 구현을 잊어 버리고 추상화 개체로만 작업할 수 있다.

장점과 단점

  • 플랫폼에 독립적인 클래스와 앱을 만들 수 있다.

  • 클라이언트 코드는 높은 수준의 추상화와 함께 작동한다. 플랫폼 세부 정보에 노출되지 않는다.

  • OCP 원칙: 서로 독립적으로 새로운 추상화와 구현을 도입할 수 있다.

  • SRP 원칙: 추상화 고수준 논리와 구현의 플랫폼 세부 사항에 집중할 수 있다.

  • High Cohesion: 클래스에 패턴을 적용하여 코드를 더욱 복잡하게 할 수 있다.

Color & Shape
Bridge Pattern