인터페이스를 만드는 시점과 변화 대비 기준
노트 유형: Cloze
Text
인터페이스는 {{c1::다형성이 필요할 때}} 만드는 것 — “모든 건 인터페이스여야 한다”는 주장이 잘못인 근거: {{c2::추상화·indirection은 인간에게 어려워서 적을수록 실수가 적음}} (협업에서는 만드는 시간보다 실수를 고치는 시간을 더 많이 씀)
- 변화에 대비할지의 판단 기준: {{c3::내가 쉽게 바꿀 수 없는 경우}}에만 인터페이스로 대비 — 이 상황 판단은 경험에서 나옴
Back Extra
- 크게 대비할 필요 없는 3가지 사례: 시스템이 크지 않음(쉽게 바꿈) / 외부 클라이언트가 적음(바꿔도 문제 겪는 쪽이 적음) / 여러 버전을 기간 한정 동시 지원(바꾸는 게 아니라 새로 만듦 — LTS·마이그레이션 가이드)
- 이클립스 API 사례 — 인터페이스에 숫자 붙이기의 동기: 아무리 설계를 잘해도 모든 미래를 예측할 수 없어 기존 인터페이스에 없는 동작을 추가할 일이 생기는데, 기존 인터페이스에 시그니처를 추가하면 모든 구현 클래스가 깨짐(약속 위반) → 대신 IWorkbenchPart2처럼 확장 인터페이스를 새로 만들어 약속도 지키고 업그레이드 옵션도 제공
- 그런데도 요즘 잘 안 하는 이유: 예측 불가는 동작 추가 수준이 아니라 설계 자체가 변하는 문제라 번호 확장으로도 한계가 있고(“애초에 모든 비즈니스 상황을 예상하고 설계할 수 없음”), 뉴비에게 어렵고, 비용이 큼 — 요즘 트렌드는 빨리 만들고 빨리 고치기
- 라이브러리 상황(011-014): 클라이언트가 인터페이스에 의존하면 라이브러리 구현이 바뀌어도 클라이언트 코드는 안 깨짐 — 단, 이 보호는 메서드 시그니처가 안 바뀐다는 전제이고(시그니처가 바뀌면 똑같이 깨짐), 그 전제가 성립하는 이유는 인터페이스 키워드가 아니라 일반화된 타입이라 바뀔 가능성이 낮기 때문 (26번 카드 c3 참고: https://pocu-site.pages.dev/pocu-note/COMP2500/anki/26-depend-on-parent-type/)