246. ISP (Interface Segregation Principle) - 인터페이스 분리 원칙 SOLID 거대 인터페이스 결합도 응집도 인터페이스 오염 객체지향 설계

핵심 인사이트: (쓸데없는 기능 강요 금지법, I) "야! 243번 SRP(단일 책임)에서 뚱뚱한 클래스를 3개로 찢었지? 이번엔 인터페이스(껍데기 계약서)다! 내가 스마트폰 충전기(인터페이스) 규격을 만들었다. 이 콘센트 규격 안에는 [충전하기], [데이터전송하기], [빔프로젝터쏘기] 구멍이 한 덩어리(뚱뚱한 만능 인터페이스)로 박혀있다. 멍청한 제조사가 선풍기에 전기를 꽂으려고 내 스마트폰 충전기 콘센트를 가져다 썼다. 근데 선풍기는 빔프로젝터를 쏠 줄 모르는데, 내 뚱뚱한 인터페이스를 쓰는 순간 억지로 그 [빔프로젝터쏘기] 함수를 빈 껍데기로라도 무조건 구현(Override)해야 에러가 안 난다! 선풍기 사장님이 빡쳤다. "야 ㅆㅂ!! 나는 전기만 빨아먹는 기능 딱 1개만 필요한데, 왜 100개짜리 쓸데없는 기능이 짬뽕 된 만능 콘센트를 나한테 꽂으라고 강요해!! 당장 콘센트 뚱뚱한 거 하나를 부숴버리고, [전기충전 콘센트], [데이터전송 콘센트] 처럼 아주 얇고 뾰족하게 100개로 찢어(Segregation) 버려!! 그래야 선풍기에는 전기 콘센트 딱 하나만 가볍게 꽂아서 쓸 거 아니야!!" 강제로 쓰레기를 먹이는 만능 인터페이스를 조각조각 찢어발기는 극세사 칼날, 인터페이스 분리 원칙(ISP)이다.

Ⅰ. 뚱뚱한(Fat) 인터페이스의 횡포

  • 개발자들이 껍데기 약속(Interface)을 만들 때 귀찮아서 무식하게 몽땅 집어넣습니다.
  • 스마트폰 인터페이스 안에 전화걸기(), 문자하기(), 카메라찍기(), 삼성페이결제하기() 를 다 때려 박았습니다.
  • 문제 발생: 최신형 갤럭시폰(클래스)은 저걸 다 상속(구현)받아 씁니다. 아주 좋습니다.
  • 재앙: 그런데 시골에 계신 할머니께 드릴 '효도폰(폴더폰)' 클래스를 새로 만들려고 저 스마트폰 인터페이스를 딱 꽂는 순간! 효도폰은 카메라와 삼성페이 기능이 하드웨어적으로 아예 없는데도, 자바 컴파일러가 강제로 카메라찍기()와 삼성페이결제하기() 함수를 코딩하라고 쌍욕(에러)을 퍼붓습니다.
  • 어쩔 수 없이 개발자는 폴더폰 코드 안에 빈 껍데기 함수(Dummy)나 throw new Exception("기능 없음") 똥 코드를 수백 줄이나 억지로 우겨넣어야 합니다. (245번 LSP 위반까지 연쇄적으로 터집니다.)

Ⅱ. ISP (Interface Segregation Principle)의 개념 🌟

  • Segregation (분리, 격리)
  • 개념: **"클라이언트(이 인터페이스를 상속받아 쓰는 객체)는 자신이 실제로 사용하지 않는 메서드(기능)에 강제로 의존(구현)하도록 강요받아서는 안 된다!"**는 아주 명쾌한 규칙입니다.
  • 해결책: 거대하고 뚱뚱한(Fat) 만능 인터페이스 1개를 쓰지 말고, 역할에 따라 쪼개서 "작고 뾰족하게 특화된 여러 개의 얇은 인터페이스들(Segregated Interfaces)"로 갈기갈기 찢어발겨서 각자 필요한 놈만 골라 쓸 수 있게 제공하라는 뜻입니다.

Ⅲ. 찢어발기기의 마법 🌟 핵심 🌟

위의 효도폰 재앙을 어떻게 구원할까요?

  1. 뚱뚱한 1개 분쇄: 스마트폰 만능 인터페이스를 파쇄기에 넣습니다.
  2. 얇은 3개로 창조:
    • [통신기기] 인터페이스 ➜ 전화걸기(), 문자하기()
    • [카메라기기] 인터페이스 ➜ 카메라찍기()
    • [결제기기] 인터페이스 ➜ 삼성페이결제하기()
  3. 선택적 레고 조립의 꿀:
    • 갤럭시폰 클래스 ➜ [통신기기], [카메라기기], [결제기기] 3개의 인터페이스를 다 갖다 꽂아서 다 구현합니다. (다중 상속의 미학)
    • 할머니 효도폰 클래스 ➜ 오직 [통신기기] 인터페이스 딱 1개만 꽂습니다!
    • 결과: 할머니 효도폰은 삼성페이나 카메라 똥 코드를 억지로 짤 필요가 0%로 사라졌습니다. 코드가 우주 끝까지 깃털처럼 가벼워집니다.

Ⅳ. 243번 단일 책임 원칙(SRP)과의 미묘한 관계

  • SRP와 ISP는 동전의 양면과 같습니다.
  • SRP (243번): 뚱뚱한 '클래스(구현체 덩어리)' 자체를 3개로 찢어발기는 것.
  • ISP (246번): 뚱뚱한 '인터페이스(껍데기 규칙서)' 자체를 3개로 찢어발기는 것.
  • 즉, 클래스(SRP)를 잘 찢어놨어도, 걔네들이 쓰는 콘센트 규칙서(인터페이스)가 하나로 뭉쳐있으면 헛수고입니다. ISP로 콘센트 규격까지 얇게 찢어놔야 비로소 진정한 레고 블록 조립 아키텍처가 완성됩니다.

📢 섹션 요약 비유: **인터페이스 분리 원칙(ISP)**은 헬스장에서 **'쓸데없는 강제 결합 요금제 금지법'**입니다. 동네 헬스장 사장님(뚱뚱한 인터페이스)이 수영장, 골프장, 헬스장, 마사지실을 다 지어놓고 '월 50만 원짜리 VIP 프리미엄 통합 회원권(Fat Interface)' 딱 한 개만 팝니다. 헬스만 하고 싶은 청년(효도폰 클래스)이 등록하러 갔더니, 사장님이 "야! 넌 수영이나 마사지 안 해도 50만 원 내고 이 통합 카드 무조건 목에 걸고 다녀(사용하지 않는 메서드 억지 구현 강요)!!"라며 갑질을 합니다. 청년은 쓰지도 않는 골프장 규칙까지 외워야 하고 돈을 낭비합니다. ISP는 이 미친 헬스장 사장의 회원권을 찢어버립니다. '수영장 전용권 5만 원', '헬스장 전용권 5만 원', '마사지 전용권 5만 원'으로 권한(인터페이스)을 갈기갈기 얇게 찢어서(Segregation) 발급합니다. 수영과 헬스만 할 사람은 딱 2개의 얇은 카드(인터페이스 2개 구현)만 사서 꽂으면 되고, 마사지실 근처에는 얼씬도 안 해도 됩니다. 내가 쓰지도 않을 거대한 권한 덩어리(메서드)를 강제로 떠안아 내 코드 파일이 썩어 문드러지고 무거워지는 것을 얇고 날카로운 메스 분할로 막아내는 인터페이스 최적화 다이어트 비법입니다.