S
UserProfile이 너무 많은 일을 한다
표시, 저장, 유효성 검사를 UserView, UserRepository, UserValidator로 나누면 변경 이유가 하나씩 분리됩니다.
원칙 이름을 외우는 것보다, 어떤 변경 이유가 섞였고 어떤 타입 계약을 분리해야 하는지 판단하는 것이 핵심입니다.
표시, 저장, 유효성 검사를 UserView, UserRepository, UserValidator로 나누면 변경 이유가 하나씩 분리됩니다.
regular, premium, vip 분기를 IDiscountStrategy 구현체로 빼면 OrderCalculator는 수정 없이 새 정책을 받습니다.
날 수 없는 타입을 Bird의 하위 타입으로 억지 배치하지 말고 Flyable과 Walkable 계약으로 나눕니다.
Workable, Codeable, Managable처럼 역할별 인터페이스를 작게 나누면 빈 구현과 오류 구현이 줄어듭니다.
구체 클래스 생성 대신 ILogger를 생성자로 주입하면 FileLogger, DatabaseLogger, 테스트용 로거를 같은 고수준 흐름에 연결할 수 있습니다.