브리지 패턴과 어댑터 패턴의 차이

StackOverflow https://stackoverflow.com/questions/1425171

  •  07-07-2019
  •  | 
  •  

문제

브리지와 어댑터 패턴의 차이점은 무엇입니까?

도움이 되었습니까?

해결책

"어댑터는 디자인 한 후에 일을하게합니다. 교량은 그들이 전에 작동하게합니다. [GOF, p219]."

효과적으로, 어댑터 패턴은 기존 코드, 타사 또는 사내이지만 제어 할 수 없거나 필요한 인터페이스를 충족시키지 못하도록 변경할 수없는 경우에 유용합니다. 예를 들어, 우리는 슈퍼 폰어 array를 가지고있어 선구자의 미세한 배열을 제어 할 수 있습니다. 

public class SuperWeaponsArray {
  /*...*/

  public void destroyWorld() {
    for (Weapon w : armedWeapons) {
      w.fire();
    }
  }
}

엄청난. 우리는 무기에 무기 인터페이스로의 전환을 크게 선행하는 핵 장치를 가지고 있다는 것을 제외하고. 그러나 우리는 그것이 여기서 일하기를 정말로 좋아합니다 ... 그래서 우리는 무엇을합니까?

NukeweAponsadaptor- Nuke 클래스를 기반으로하지만 무기 인터페이스를 수출합니다. 달콤한, 이제 우리는 세상을 반드시 파괴 할 수 있습니다. 약간의 kludge처럼 보이지만 일이 작동합니다.

그만큼 다리 패턴은 당신이 앞쪽으로 구현하는 것입니다. 두 개의 직교 계층이 있다는 것을 알고 있다면 인터페이스와 구현을 해체 할 수있는 방법을 제공합니다. 당신이 가지고 있다고 가정 해 봅시다 :

MemoryMappedFile 및 DirectreadFile 유형의 파일 개체. 다양한 소스 (Linux 대 Windows 구현 등)에서 파일을 읽을 수 있다고 가정 해 봅시다. 브리지는 다음과 같은 영향을 피하는 데 도움이됩니다.

MemoryMappedWindowsFile MemoryMappedLinuxFile DiRectreadWindowsFile DirectreadlinuxFile

다른 팁

http://en.wikipedia.org/wiki/adapter_pattern

어댑터 패턴은 기존 코드가 최신 시스템 또는 인터페이스에서 작동하도록하는 것입니다.

다른 응용 프로그램의 기존 확장 성 인터페이스에 제공하려는 회사 표준 웹 서비스 API 세트가있는 경우이를 수행하기 위해 어댑터 세트를 작성하는 것이 좋습니다. 회색 영역이 있으며 이는 정면과 같은 다른 패턴이 비슷하기 때문에 패턴을 기술적으로 정의하는 방법에 더 유용합니다.

http://en.wikipedia.org/wiki/bridge_pattern

브리지 패턴을 사용하면 알고리즘이나 시스템의 대체 구현이 가능할 수 있습니다.

고전적인 브리지 패턴 예제는 아니지만 데이터 저장소의 몇 가지 구현이 있다고 상상해보십시오. 하나는 공간이 효율적이고 다른 하나는 원시 성능이 효율적이며 앱이나 프레임 워크에 모두 제공하는 비즈니스 사례가 있습니다. .

"내가 어떤 패턴을 사용할 수있는 곳"의 질문에 따르면, 대답은 프로젝트에 적합한 곳이라면 어디에도 있습니다! 아마도 설명 편집을 제공하는 것을 고려하여 하나 또는 다른 것을 사용해야한다고 생각하는 위치에 대한 토론을 안내하십시오.

어댑터:

  1. 구조적 패턴입니다
  2. 두 개의 호환되지 않는 인터페이스에서 작업하는 것이 유용합니다

UML 다이어그램 : ~에서 도 팩토리 기사:

enter image description here

표적 : 클라이언트가 사용하는 도메인 별 인터페이스를 정의합니다.

어댑터 : 인터페이스 어댑티를 대상 인터페이스에 조정합니다.

어댑티 : 적응이 필요한 기존 인터페이스를 정의합니다.

고객 : 대상 인터페이스를 준수하는 개체와 협력합니다.

예시:

정사각형과 사각형은 서로 다른 두 가지 모양이며 각각의 영역 ()은 서로 다른 방법이 필요합니다. 그러나 일부 속성의 변환과 함께 사각형 인터페이스에서 여전히 제곱이 작동합니다.

public class AdapterDemo{
    public static void main(String args[]){
        SquareArea s = new SquareArea(4);
        System.out.println("Square area :"+s.getArea());
    }
}

class RectangleArea {
    public int getArea(int length, int width){
        return length * width;
    }
}

class SquareArea extends RectangleArea {

    int length;
    public SquareArea(int length){
        this.length = length;
    }
    public int getArea(){
        return getArea(length,length);
    }
}

다리:

  1. 구조적 패턴입니다
  2. 그것은 구현에서 추상화를 분리하고 둘 다 독립적으로 다를 수 있습니다.
  3. 상속 대신에 구성이 사용 되었기 때문에 가능합니다.

편집하다: (@Quasoft 제안에 따라)

이 패턴에는 네 가지 구성 요소가 있습니다.

  1. 추출: 인터페이스를 정의합니다

  2. 정교함: 추상화를 구현합니다.

  3. 구현 자: 구현을위한 인터페이스를 정의합니다

  4. 콘크리트 이식기: 구현 자 인터페이스를 구현합니다.

코드 스 니펫 :

Gear gear = new ManualGear();
Vehicle vehicle = new Car(gear);
vehicle.addGear();

gear = new AutoGear();
vehicle = new Car(gear);
vehicle.addGear();

관련 게시물 :

브리지 패턴은 언제 사용합니까? 어댑터 패턴과 어떻게 다른가요?

주요 차이점 : ~에서 사워 메이킹 기사

  1. 어댑터는 설계 후 일을 작동시킵니다. 다리는 그들이 전에 일하기 전에 일하게합니다.
  2. 브리지는 추상화와 구현이 독립적으로 다양하도록 선형으로 설계되었습니다. 어댑터는 관련된 클래스를 함께 작동 시키도록 개조되어 있습니다.

이 게시물은 꽤 오랫동안 주변에있었습니다. 그러나 외관은 어댑터와 다소 비슷하지만 그다지 똑같지는 않다는 것을 이해하는 것이 중요합니다. 어댑터는 기존 클래스를 일반적으로 비 호환 클라이언트 클래스에 "적응"합니다. 응용 프로그램이 클라이언트로 사용하는 오래된 워크 플로 시스템이 있다고 가정 해 봅시다. 회사는 워크 플로 시스템을 새로운 "호환되지 않는"(인터페이스 측면에서)로 교체 할 수 있습니다. 대부분의 경우 어댑터 패턴을 사용하고 실제로 새 워크 플로 엔진의 인터페이스를 호출하는 코드를 작성할 수 있습니다. 다리는 일반적으로 다른 방식으로 사용됩니다. 실제로 다른 파일 시스템 (예 : 로컬 디스크, NFS 등)으로 작업 해야하는 시스템이있는 경우 브리지 패턴을 사용하여 하나의 추상화 레이어를 만들어 모든 파일 시스템과 작동 할 수 있습니다. 이것은 기본적으로 브리지 패턴의 간단한 사용 사례입니다. 외관과 어댑터는 몇 가지 속성을 공유하지만 정면은 일반적으로 기존 인터페이스/클래스를 단순화하는 데 사용됩니다.. EJBS의 초기에는 EJB에 대한 지역 요구가 없었습니다. 개발자들은 항상 스터브를 얻었고, 좁히고 그것을 "유사 적으로"라고 불렀습니다. 이것은 종종 성능 문제를 일으켰습니다 (Esp. 실제로 와이어 위로 호출 될 때). 숙련 된 개발자는 정면 패턴을 사용하여 클라이언트에게 매우 거친 입자 인터페이스를 제공합니다. 이 외관은 차례로 다른 세밀한 방법에 대한 여러 호출을 할 것입니다. 대체로, 이로 인해 필요한 방법 호출 수가 크게 줄어들고 성능이 향상되었습니다.

(일반/초록) 드로잉 기능과 모양을 구현하는 원이있는 추상 모양 클래스라고 가정 해 봅시다. 브리지 패턴은 단순히 구현 (원으로 그리기) 및 제네릭/초록 기능 (모양 클래스에서 그리기)을 분리하기위한 양방향 추상화 접근법입니다.

정말 무슨 뜻인가요? 언뜻보기에, 그것은 당신이 이미 만들고있는 것 (의존성 반전)처럼 들립니다. 따라서 덜 리그 또는 더 많은 모듈 식 코드베이스를 갖는 것에 대해 걱정할 필요가 없습니다. 그러나 그것은 그 뒤에 약간 더 깊은 철학입니다.

내 이해로부터, 현재 시스템과 밀접한 관련이있는 새로운 클래스 (Redcircle 또는 Greencircle과 같은)와 단일 기능 (색상 등)에 의해서만 다른 새로운 클래스를 추가해야 할 때 사용 패턴의 필요성이 나타날 수 있습니다. 특히 기존 시스템 클래스 (원 또는 모양)가 자주 변경되어 새로 추가 된 클래스가 이러한 변경으로 인해 영향을 받기를 원하지 않는 경우 브리지 패턴이 필요합니다. 그래서 제네릭 드로잉 기능이 새 인터페이스로 추상화되어 모양이나 원과 독립적 인 도면 동작을 변경할 수 있습니다.

브리지는 어댑터가 향상되었습니다. 브리지에는 어댑터가 포함되어 있으며 추가 유연성이 추가됩니다. 다음은 Ravindra의 답변 맵에서 패턴 간의 요소를 다음과 같습니다.

      Adapter  |    Bridge
    -----------|---------------
    Target     | Abstraction
    -----------|---------------
               | RefinedAbstraction
               |
               |   This element is Bridge specific. If there is a group of 
               |   implementations that share the same logic, the logic can be placed here.
               |   For example, all cars split into two large groups: manual and auto. 
               |   So, there will be two RefinedAbstraction classes.
    -----------|--------------- 
    Adapter    | Implementor
    -----------|---------------
    Adaptee    | ConcreteImplementor
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top