브릿지 패턴에서 다시 컴파일하면 어떤 혼란이 있습니다.임 플리 멘 테이션을 디커플링하고 클라이언트 측에서 재 컴파일을 피하는 브릿지 패턴 도움 방법
예를 들어 구현을 변경하면 추상 구현 인터페이스를 사용하면 클라이언트 코드가 다시 컴파일되지 않는 데 도움이되는 이유는 무엇입니까? "windowImp.h"를 포함하는 "window.h"를 포함하는 클라이언트는 결국이 두 클래스의 모든 부분을 전 처리기 프로세스 동안 클라이언트 코드에 추가합니다.
누군가가 컴파일러가 각 유닛을 컴파일하는 방법과 구현이 변경된 시점에서 이점을 설명 할 수 있습니까? 왜 클라이언트가 다시 연결해야합니까?
컴파일러는 기본적으로 각 cpp 파일을 개별적으로 컴파일 한 다음 출력을 연결합니다. 이 cpp 또는 cpp 자체에서 사용되는 include 중 하나를 변경 한 경우, 해당 cpp를 다시 컴파일해야합니다 (증분 빌드를 수행하는 경우).
cpp 파일 foo.cpp에 bar.h 헤더가 포함되어 있다고 가정 해 보겠습니다. bar.h는 foobar 클래스를 정의합니다. foobar의 private 변수 (구현 세부 사항)를 변경하면 foo.cpp를 다시 컴파일해야합니다. 추상 기본 클래스 (예 : Ifoobar in ibar.h)를 만들면 foo.cpp에 ibar.h가 포함될 수 있습니다. bar.h의 구현 세부 사항을 변경하면 foo.cpp를 강제로 재 컴파일하지 않습니다. 이 클래스 foobar가 수천 개의 파일에 사용되어 많은 컴파일 시간을 절약했다고 가정합니다.
감사 토비아스
들으, 나는 전처리 과정에서 캐스케이드 효과의 원인이됩니다 IMPL 클래스의 혼란에 자신의 시간의 파일과 구현 세부 사항의 변경 사항이 실행되었다. 그러나 실제로 제품 측면은 #include "implInterface"이지만 실제 h 파일은 포함하지 않습니다. 귀하의 대답은 단순히이 두 개념을 명확하게 구분합니다. – user2984297
자세한 내용이 필요하면 "Large Scale C++ Software Design"을 살펴보십시오. 조금 오래되었지만 대부분은 여전히 사실입니다. –