SOLID 적용 기준

원칙 이름보다 변경 지점과 타입 경계를 먼저 본다

SOLID는 외울 규칙이 아니라 수정이 자주 일어나는 곳을 책임, 확장, 대체 가능성, 인터페이스, 추상화 경계로 다시 나누는 설계 점검표입니다.

원칙별 리팩터링 매트릭스
SRP 한 클래스가 저장, 검증, 출력까지 모두 처리한다. 변경 이유별로 책임을 나누고 역할 타입을 분리한다. 책임 분리
OCP 조건문을 계속 추가해야 새 기능이 붙는다. 공통 interface를 두고 구현체를 추가하는 구조로 바꾼다. 확장 열기
LSP 자식 타입이 부모 계약을 깨서 예외 조건이 늘어난다. 대체 가능한 계약만 부모 타입에 남긴다. 계약 보존
ISP 사용하지 않는 메서드까지 구현해야 한다. 호출자 목적별로 작은 인터페이스를 나눈다. 면적 축소
DIP 고수준 로직이 파일, DB, 콘솔 구현체를 직접 안다. 추상화에 의존하고 생성자 주입으로 구현체를 받는다. 의존 역전
TypeScript 설계 장치
interface 구현체 교체 지점을 호출부에서 숨긴다.
abstract class 공통 구현과 필수 구현 계약을 함께 둔다.
generic 타입 안정성을 유지한 채 재사용 범위를 넓힌다.
나쁜 신호와 좋은 신호
나쁜 신호 새 기능마다 기존 클래스와 테스트를 넓게 수정
좋은 신호 새 구현체 추가가 기존 고수준 로직을 건드리지 않음
검증 신호 mock 구현체로 같은 계약을 테스트할 수 있음
리뷰 순서
01 변경 이유 찾기 같은 클래스가 왜 자주 바뀌는지 본다.
02 호출자 나누기 필요한 메서드 집합이 같은지 확인한다.
03 추상화 세우기 고수준 정책이 구현체 이름을 모르게 한다.
04 대체성 확인 자식 타입이 부모 계약을 깨지 않는지 본다.