260. 브리지 (Bridge) - 구현부에서 추상층을 분리 구조 패턴 다중 상속 문제 해결 OCP 결합도 감소 확장성 독립적 진화

핵심 인사이트: (258번 구조 패턴의 두 번째) '리모컨'과 'TV'를 만들어야 한다. 삼성 TV 리모컨, LG TV 리모컨, 삼성 에어컨 리모컨, LG 에어컨 리모컨... 브랜드 2개, 가전제품 2개인데 멍청하게 통짜로 상속을 쓰니까 벌써 클래스(자식)를 4개나 new 로 찍어내야 한다! 내일 애플과 소니가 참전하고 냉장고가 추가되면? 3 x 3 = 9개의 끔찍한 클래스 파일 파티가 열린다(다중 상속 폭발). "야 ㅆㅂ!! 언제까지 껍데기(리모컨)랑 알맹이(TV)를 한 몸통의 상속 관계로 억지로 묶어둘래!! 껍데기 가계도(추상층)랑 알맹이 가계도(구현층)를 도끼로 내리쳐서 두 동강을 내버려!! 그리고 그 사이를 얇은 '다리(Bridge)' 하나로만 찍 이어버려!! 그럼 리모컨 쪽에 껍데기를 100개 추가하든, TV 쪽에 알맹이를 100개 추가하든, 서로의 가계도는 1%도 간섭 안 받고 자기들끼리 자유롭게 무한 확장(진화) 할 수 있잖아!!" 껍데기와 속살의 이혼 서류에 도장을 찍어 상속 폭발을 막아낸 마법의 다리, 브리지 패턴이다.

Ⅰ. 상속(Inheritance)의 끔찍한 덫: 콤비네이션 폭발

• 객체지향 초보들은 기능이 추가될 때마다 부모 클래스 밑에 자식 클래스를 덧붙이는(extends) **'상속'**을 미친 듯이 씁니다.
• 비극의 상황: 모양(Shape)이라는 부모가 있습니다. 자식으로 원, 네모가 있습니다. 여기에 색깔 기능을 추가하려 합니다.
• 멍청한 설계: 빨간원, 파란원, 빨간네모, 파란네모. 기능(모양)과 구현(색깔)이 한 핏줄(상속)로 강하게 얽혀있습니다.
• 만약 모양에 '세모'가 추가되고 색깔에 '노란색'이 추가되면? 3(모양) x 3(색깔) = 9개의 클래스 파일이 우수수 떨어집니다. 수정과 확장이 지옥이 됩니다.

Ⅱ. 브리지 (Bridge) 패턴의 개념 🌟

• 개념: GoF 구조 패턴 중 하나로, 기능의 껍데기 계층(추상화 Abstraction)과 실제 속살을 동작시키는 계층(구현 Implementation)을 하나의 뚱뚱한 족보(상속)로 묶지 않고, 물리적으로 완전히 독립된 두 개의 클래스 가계도로 찢어 분리한 뒤, 둘 사이를 객체 위임(합성, Bridge)으로 느슨하게 연결하여 두 계층이 서로 독립적으로 무한 확장(진화)할 수 있게 만드는 패턴입니다.

Ⅲ. 도끼로 찢고 다리로 잇는 마법 🌟 핵심 기출 🌟

어떻게 9개의 클래스를 5개로 줄여버릴 수 있을까요?

1. 완벽한 분리 (도끼질):
   • [모양] 가계도(껍데기) ➜ 부모: Shape, 자식: 원, 네모 (여기엔 색깔 코드를 1줄도 안 넣습니다!)
   • [색깔] 가계도(속살) ➜ 부모: Color 인터페이스, 자식: 빨강, 파랑
2. 다리 놓기 (Bridge 연결):
   • 껍데기 부모인 Shape의 뱃속(멤버 변수)에다가, 색깔의 부모인 Color 인터페이스를 변수로 쏙 품어버립니다(이것이 브리지, 합성 Composition 입니다).
   • 이제 원은 자신이 무슨 색깔인지 모릅니다. 그저 색칠할 때가 되면 뱃속에 품고 있는 Color.칠해라() 다리 건너편의 스위치를 누릅니다.
3. 기적의 결과 (독립적 진화):
   • 만약 내일 당장 "초록색"을 추가해야 한다면? 옛날엔 초록원, 초록네모 2개를 짜야 했지만, 브리지 패턴에서는 그냥 [색깔] 가계도 쪽에 초록 자식 클래스 딱 1개만 찍어내면 끝납니다!! (확장성 폭발, OCP 완벽 준수)
   • [모양] 놈들은 초록이 생겼는지 1%도 관심 없이 평생 자기 할 일만 하며 살아갑니다.

Ⅳ. 언제 브리지를 써야 하는가? (플랫폼 독립성)

• 껍데기는 변하지 않는데, 그 속에서 돌아가는 구동 환경(운영체제, DB 등)이 미친 듯이 여러 개로 나뉘고 계속 추가될 때 씁니다.
• 예: 게임 앱(껍데기)은 1개인데, 이게 Windows용, Mac용, Linux용 등 플랫폼(알맹이)에 맞춰서 렌더링을 3가지로 다르게 해야 할 때. 플랫폼이 10개로 늘어나도 껍데기 게임 코드는 1줄도 고치지 않기 위해 브리지의 다리를 놓습니다.

📢 섹션 요약 비유: 브리지(Bridge) 패턴은 스마트폰 제조사의 **'기기 껍데기와 통신사 유심(USIM)칩의 완벽한 이혼 서류'**와 같습니다. 옛날 바보 같은 제조사(상속 떡칠)는 폰 안에 통신사 모듈을 용접해 버렸습니다. "SKT용 아이폰", "KT용 아이폰", "LG용 아이폰" 이렇게 물리적으로 다른 폰 3대를 찍어내야(클래스 3개 생성) 했습니다. 만약 '아이폰 미니' 모델이 추가되면 폰 공장은 2개 모델 x 3개 통신사 = 6대의 다른 기계를 생산해야 하는 지옥(상속 폭발)이 열렸습니다. 빡친 애플(브리지 패턴)은 폰과 통신 모듈을 완전히 쪼개버립니다(분리). 애플은 오직 **'껍데기 기기(Abstraction 추상층)'**만 죽어라 찍어냅니다. 그리고 폰 옆구리에 작은 **'유심칩 트레이(Bridge 다리)'**만 텅 빈 채로 뚫어놓습니다. 통신사들은 애플 눈치 볼 필요 없이 자기들끼리 마음대로 규격에 맞는 **'유심칩(Implementation 구현층)'**만 100만 개를 찍어냅니다(독립적 확장). 소비자는 그냥 예쁜 아이폰(껍데기)을 하나 사고, 자기가 원하는 SKT 유심칩(속살)을 트레이에 '찰칵' 끼워 넣기(위임 연결)만 하면 전화가 터집니다! 폰 껍데기 라인업이 100개로 늘든, 통신사가 100개로 늘든 서로의 공장은 단 1%의 타격도 받지 않고 평생 독자적으로 무한 진화(OCP)할 수 있는 조립식 생태계의 기적입니다.