인터페이스 분리 원칙(ISP): 큰 인터페이스가 왜 문제이고 언제 나눠야 할까
인터페이스 분리 원칙(ISP)을 슬로건처럼 외우면 실무에서 잘 안 보입니다. 이 글에서는 큰 인터페이스가 왜 변경 비용과 테스트 비용을 키우는지, 언제 역할별 계약으로 나누는 것이 좋은지 실전 기준으로 정리합니다.
-
-
상속보다 조합이 더 나은 순간: 객체지향 설계에서 조합을 고르는 기준
상속보다 조합이 더 나은 순간은 분명합니다. 이 글에서는 객체지향 설계에서 조합을 고르는 기준을 변경 비용, 역할 재사용, 위임, 치환 가능성, 옵션 조합 관점으로 실무적으로 정리합니다.
-
리스코프 치환 원칙(LSP)은 왜 자주 오해될까: 상속보다 계약을 먼저 봐야 하는 이유
리스코프 치환 원칙(LSP)을 상속 문법이 아니라 계약과 치환 가능성 관점에서 다시 설명합니다. 상속이 자연스러운지 판단하는 실전 질문과 구체적인 위반 사례까지 함께 정리합니다.
-
SOLID 원칙, 실무에서는 어떻게 봐야 할까
SOLID 원칙을 암기나 의식처럼 적용하지 않고, 변경 비용·계약·의존성 관점에서 다시 설명합니다. 실무에서 자주 생기는 오해와 과한 추상화 문제까지 함께 정리합니다.
-
인터페이스는 왜 필요할까: 구현 분리보다 더 중요한 설계상의 이점 정리
인터페이스는 왜 필요할까를 구현 분리 한 줄로만 설명하면 설계의 핵심을 놓치기 쉽습니다. 이 글에서는 역할 분리, 변경 비용, 테스트 가능성, 협업 경계 관점에서 인터페이스의 진짜 가치를 쉽게 정리합니다.
-
추상 클래스와 인터페이스 차이: 자바와 객체지향 설계 관점에서 언제 무엇을 써야 할까
추상 클래스와 인터페이스 차이를 자바 문법 비교표로만 외우면 실무에서 자주 헷갈립니다. 이 글에서는 공통 상태, 계약, 다중 타입, 변경 비용 관점에서 언제 무엇을 쓰면 좋은지 쉽게 정리합니다.
