Design Pattern) 구조패턴 #1 - Bridge Pattern

구조패턴이란 ? 

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나

객체들을 서로 묶어 새로운 기능을 제공하는 패턴 !

 

구조패턴 특징 !

- 서로 독립적으로 개발한 클래스 라이브러리를 마치 하나인 것처럼 사용할 수 있다.

- 여러 인터페이스를 합성하여 서로 다른 인터페이스들의 통일된 추상을 제공한다.

- 인터페이스나 구현을 복합하는 것이 아니라 객체를 합성하는 방법을 제공한다. 

 

구조패턴 종류 

 

Bridge

Decorator

Facade

Flyweight

Proxy

Composite

Adaptor

 

오늘은 위의 7가지 중에서 Bridge 패턴에 대해 알아보겠습니다 !

 

 

 

---

Bridge Pattern 

브릿지 패턴은 구현부에서 추상층을 분리하여 각자 독립적으로 변형이 가능하고

확장이 가능하도록 하는 패턴 ! 

 

즉 기능과 구현에 대해서 두 개의 별도 클래스로 구현을 할 수 있도록 하는 

구조 설계 관련 패턴입니다 

 

Bridge 패턴은 객체의 다중 상속 구조를 피하면서 독립적으로 확장을 할 수 있도록 도와줍니다. 

 

 

Abstraction : 기능 계층의 최상위 클래스.

구현 부분에 해당하는 클래스를 인스턴스를 가지고 해당 인스턴스를 통해 구현부분의 메서드를 호출합니다.

 

RefindAbstraction : 기능 계층에서 새로운 부분을 확장한 클래스

 

Implementor : Abstraction의 기능을 구현하기 위한 인터페이스 정의

 

ConcreteImplementor : 실제 기능을 구현합니다.

 

 

 

Bridge 패턴을 사용하면 아래와 같은 다중 상속 구조를 확장이 용이하며

다중 상속을 피한 구조로 변경할 수 있다고 합니다 ! 

 

 

 

// Implementor : Abstraction 기능을 구현하기 위한 인터페이스 정의
protocol Car {
    // implementation()
    func drive()
}

// ConcreteImplementor : 실제 기능을 구현하는 클래스 1
class Sedan : Car {
    // implementation()
    func drive() {
        print("Drive a sedan")
    }
}

// ConcreteImplementor : 실제 기능을 구현하는 클래스 2
class SUV : Car {
    func drive() {
        print("Drive a SUV")
    }
}

// Abstraction : 기능 계층의 최상위
protocol ColoredCar {
    // implementor
    var car: Car { get set }
    
    // implementation()
    func drive()
}

// RefinedAbstraction : 기능계층에서 새로운 부분 확장
class RedCar: ColoredCar {
    // implementor
    var car: Car
    
    init(car: Car) {
        self.car = car
    }
    
    // refinedFunction()
    func drive() {
        print("It's a red color sedan.")
        
        // self.impl.implementation()
        car.drive()
    }
}

let sedan = Sedan()
let redSedan = RedCar(car: sedan)
        
redSedan.drive()
        
// It's a red color sedan.
// Drive a sedan

다중상속을 피하면서 독립적으로 확장한다는게 핵심개념인 것 같은데 잘 이해가 안되는거 같아서 더 찾아봐야지

 

구현층 추상층 분리 ! 

 

 

 

 

+ 줄글로 설명된 예시 

 

Shape라는 클래스가 있고 Shape의 하위 클래스로 Circle, Square가 있는 예를 들어볼게요. 현재 클래스 계층구조를 확장하여 Color를 갖는 Shape 클래스를 만들고 싶다고 가정해보겠습니다. 파란색 Circle, Square를 만들고 싶다고 할 때 각각 BlueCircle, BlueSquare 클래스를 만들게 되면 어떻게 될까요? 매번 색을 하나씩 추가할 때마다 너무 많은 서브 클래스가 생겨나게 됩니다.

 

이러한 문제는 Shape와 Color 클래스의 개념을 독립적으로 확장하려고 했기 때문에 발생한 일인데요, 브리지 패턴은 이러한 문제를 객체 구성으로 전환하여 해결합니다. Color 클래스 객체와 Shape 클래스 객체를 나누어 생각하는 거예요. 만약 Color 클래스 객체로 Blue, Red를 만들었다면 Shape 클래스의 객체가 이를 참조하여 사용하게 할 수 있으며 이러한 참조가 Bridge 역할을 하게 됩니다.

 

브리지 패턴의 결과

종속성이 없는 인터페이스와 구현부를 가질 수 있습니다.

추상화의 구현은 런타임에서 구성할 수 있기 때문에 객체가 런타임에서 구현부를 변경할 수도 있습니다.

이렇게 추상화와 구현을 분리하면 구현에 대한 컴파일 시간 종속성도 제거되며

구현 클래스를 변경하기 위해 Abstraction 클래스와 해당 클라이언트를 다시 컴파일할 필요가 없어집니다.

 

코드의 확장성이 좋아집니다.

 

클라이언트로부터 구현의 세부 사항을 숨길 수 있습니다. 구현 클래스의 객체 공유 및 참조 카운트 메커니즘과 같은 세부 정보로부터 클라이언트를 보호할 수 있습니다.

출처: https://icksw.tistory.com/242?category=944177 [PinguiOS]

 

 

 

 

참고 !

 

[디자인패턴] Bridge(브릿지) : 기능과 구현을 분리하여 독립적 변경과 확장을 용이하게 하는 패턴