여전히 구현이 추상화에서 파생되는 브리지 패턴입니까?

Question

유도 API가 아닌 인 공용 API 클래스를 제공 할 때 브릿지를 추가하고 구현하는 대신 해당 클래스에서 파생하여 구현을 제공하는 것이 더 편리하다는 것을 알게되었습니다.

추상화 의 구현은으로 대체 할 필요가 없습니다. 유일한 요구 사항은 구현을 추상화 (공용 인터페이스)와 분리하는 것입니다.

PublicApiAssembly.dll :

public abstract class PublicApi // Clients don't need to derive from it 
{ 
    internal PublicApi() {} 
    public abstract void Calculate(); 
} 

ImplementationAssembly.dll (참조 PublicApiAssembly.dll 다른 모든 종속성이 추상화를 구현하는) :

internal class PublicApiImpl : PublicApi 
{ 
    public override void Calculate() {} 
} 

는 여전히 다리 패턴 구현 도출인가 추상화에서 제발, 제발?

Wikipedia 나는 "책임을 분리하기 위해 상속을 사용할 수있다"고 말할 때 브리지 패턴을 구현한다고 생각하게했습니다.

감사합니다.

Answer 1

브리지 패턴의 핵심은 "추상화를 구현과 분리하여 두 가지가 서로 다를 수 있습니다. 독립적으로"입니다. 추상화은 상속을 통해 다양 할 수 있지만 구현은 구현에 따라 다를 수 있습니다. 이것은 더 이상 당신의 디자인에 해당하지 않습니다. 의도적으로 추상화가 달라지지 않을 것이라고 ("파생을위한 의미가없는 공용 API 클래스") 구현을 상속을 통해 추상화에 묶었습니다. 그래서 IMHO는 그것을 언급하는 것을 정당화하기 위해 여기에 다리 패턴이 충분하지 않습니다. 사이드 참고로

:

유일한 요구 사항은 추상화의 구현 (공중 인터페이스)를 분리하는 것이다.

PublicApi을 인터페이스 대신 추상 클래스로 모델링하는 이유는 무엇입니까? 당신의 질문에서 읽은 것에서 인터페이스가 당신의 의도와 더 잘 어울릴 것입니다.