프로그래머가 구현을 인터페이스와 분리하려는 이유는 무엇입니까?

브릿지 디자인 패턴 은 구현을 프로그램의 인터페이스와 분리합니다.

이것이 왜 유리합니까?

인터페이스와 독립적으로 구현을 변경할 수 있습니다. 이는 변화하는 요구 사항을 처리하는 데 도움이됩니다.

전형적인 예는 인터페이스의 스토리지 구현을 시스템의 나머지 부분을 변경하지 않고 더 크고, 더 좋고, 더 빠르거나, 더 작거나 다른 것으로 대체하는 것입니다.

Daniel의 답변 외에도 구현과 다형성 과 같은 개념을 통해 인터페이스를 분리 하면 서로 다른 방식으로 유사한 일을하는 동일한 인터페이스의 여러 구현을 만들 수 있습니다.

예를 들어, 많은 언어는 표준 라이브러리 어딘가에 스트림 개념을 가지고 있습니다. 스트림은 직렬 액세스를위한 데이터를 보유하는 것입니다. 읽기 (스트림에서 다음 X 바이트 수로드) 및 쓰기 (X 바이트의 데이터 바이트 추가)와 세 번째 탐색 (스트림의 "현재 위치"재설정)이라는 두 가지 기본 작업이 있습니다. 새 위치로).

그것은 충분히 간단한 개념이지만, 당신이 할 수있는 모든 것을 생각하십시오. 가장 확실한 방법은 디스크의 파일과 상호 작용하는 것입니다. 파일 스트림을 사용하면 파일에서 데이터를 읽거나 쓸 수 있습니다. 그러나 대신 네트워크 연결을 통해 데이터를 보내려면 어떻게해야합니까?

구현에 직접 의존하는 경우 동일한 데이터를 파일에 저장하거나 네트워크를 통해 보내려면 완전히 다른 두 가지 루틴을 작성해야합니다. 그러나 스트림 인터페이스 가 있으면 필요한 곳으로 데이터를 전송하는 특정 세부 정보를 캡슐화하는 두 가지 다른 구현 ( FileStream및 NetworkStream)을 만들 수 있으며 파일 저장을 처리하는 코드 만 작성하면됩니다. . 갑자기 당신 SaveToFile과SendOverNetwork 루틴은 훨씬 간단합니다. 그들은 적절한 유형의 스트림을 설정 SaveData하고 스트림 인터페이스를 허용하는 루틴으로 전달합니다 . 이것은 수행 할 수있는 한 어떤 유형을 신경 쓰지 않아도됩니다 쓰기 작업-데이터를 스트림에 저장합니다.

또한 데이터 형식이 변경되면 여러 위치에서 데이터 형식을 변경할 필요가 없습니다. 스트림을 사용하는 하나의 루틴으로 데이터 저장 코드를 중앙 집중화하는 경우 업데이트해야하는 유일한 곳이므로 둘 다 변경해야 할 때 한 곳만 변경하여 실수로 버그를 발생시킬 수 없습니다. 따라서 인터페이스를 구현에서 분리하고 다형성을 사용하면 코드를 읽고 이해하기가 더 쉽고 버그가 적습니다.

여기에 관련된 두 가지 질문이 있습니다.

더 일반적인 질문은 제목에있는 질문입니다. 왜 인터페이스와 일반적인 구현을 분리해야합니까? 두 번째 질문은 브리지 패턴이 유용한 이유입니다. 브리지 패턴은 인터페이스를 구현에서 분리하는 특정 방법이기 때문에 관련이 있으며, 이는 다른 결과도 있습니다.

일반적인 질문은 모든 프로그래머가 이해해야 할 중요한 것입니다. 프로그램의 변경 사항이 모든 곳에서 전파되는 것을 방지합니다. 인간이 이것을 사용하지 않고 프로그래밍 할 수 있다고 상상할 수 없습니다.

프로그래밍 언어로 간단한 추가 문장을 작성할 때, 이미 추상화되어 있습니다 (매트릭스 또는 이와 유사한 것을 추가하기 위해 연산자 오버로드를 사용하지 않는 경우에도). 컴퓨터의 회로에 구현 (머신 코드 묶음)과 인터페이스가 분리되지 않은 경우 (예 : "3 + 5") 구현이 변경 될 때마다 코드를 변경해야합니다 (예 : 새 프로세서).

간단한 CRUD 응용 프로그램 내에서도 모든 메서드 서명은 광범위하게 구현을위한 인터페이스입니다.

이러한 모든 종류의 추상화는 동일한 기본 목표를가집니다. 호출 코드는 구현 자에게 필요한만큼 많은 정보를 제공 할 수있는 가장 추상적 인 방식으로 의도를 표현합니다. 그것은 그들 사이에 가능한 최소한의 결합을 제공하고, 코드를 가능한 많이 변경해야 할 때 파급 효과를 제한합니다.

간단하게 들리지만 실제로는 복잡해집니다.

브릿지 패턴은 특정 구현 비트를 인터페이스로 분리하는 특정 방법입니다. 패턴의 클래스 다이어그램은 설명보다 유익합니다. 브리지보다 플러그 가능한 모듈을 사용하는 방법과 비슷하지만 인터페이스 이전에 모듈이 생성 된 위치에서 자주 사용되기 때문에 브리지로 명명되었습니다. 따라서 유사한 기존 구현을위한 공통 인터페이스를 만들면 차이점을 "교량"하고 모든 구현에서 코드를 사용할 수 있습니다.

따라서 워드 프로세서에 애드온을 작성하고 싶지만 여러 워드 프로세서에서 작동하기를 원한다고 가정하십시오. 필요한 워드 프로세서 기반 기능을 추상화하고 (변경할 수 없으므로 각 워드 프로세서에서 구현할 수있는) 기능을 지원하는 인터페이스와 지원하려는 각 워드 프로세서에 대해 해당 인터페이스의 구현을 생성 할 수 있습니다. 그런 다음 응용 프로그램에서 해당 인터페이스를 호출하고 각 워드 프로세서의 세부 정보에 대해 걱정하지 않아도됩니다.

각 클래스가 실제로 클래스 계층 구조 일 수 있기 때문에 실제로 약간 더 상세합니다 (따라서 추상 워드 프로세서뿐만 아니라 각각에 대한 구체적인 구현과 함께 추상 문서, 추상 TextSelection 등이있을 수 있음). 같은 생각.

추상화 레이어는 여러 기본 시스템에 동일한 인터페이스를 제공하는 데 중점을 둔다는 점을 제외하면 정면과 비슷합니다.

구체적 구현자는 메소드 또는 생성자에 전달되고 호출 된 실제 구현을 결정하기 때문에 Inversion Of Control과 관련이 있습니다.