📍 이 글은 스스로 자주 보기 위해 원글을 엄청나게 압축한 요약글입니다. 더 상세한 내용을 볼 수 있는 Myners님의 testable code 시리즈와 영어 원문을 추천드립니다.
TODO
- SRP 원칙을 지켜라
- 너무 많은 일을 하는 생성자를 주의해라
- 너무 많은 일을 하는 클래스를 주의해라
- 레거시일 경우 새로운 클래스부터라도 SRP를 지켜서 만들어라
- 디미터 법칙을 지켜라
- 직접 찾지 말고, 실제 사용될 객체를 주입받아라
- 낯선 자에게 말하지 마라
- (추가) 디미터 법칙에 대한 다양한 의견이 있으니 단순히 체인 1개 이상으로만 생각하진 말자
- API의 의존성을 명확히 나타내라
- 메서드 시그니처나 생성자에 표현되어야 함
- Hidden interactions을 피할 것
- Dependency Injection is your Friend
collaborator를 직접 생성하지 말고 주입받아라
- static, global state, singleton 사용을 멀리해라
Warning signs
- 클래스
- 생성자가 필드 할당 외에 다른 하는 일이 있는 경우
- 초기화 블럭을 사용한 경우
- 클래스 이름을 짓기 어렵거나, 모호한 단어가 어울리는 경우
- 클래스가 하는 일을 표현할 때 AND가 들어가는 경우
- 클래스에 일부 메서드에서만 사용되는 필드가 있는 경우
- 너무 많은
collaborators나 무능한collaborator가 존재하는 경우
- 메서드
- 전달되는 객체가 직접 사용되지 않는 경우
- getter 메서드의 호출 체인이 여러 번 발생하는 경우
- 광범위한 이름의 객체와 상호 작용하는 경우 (ex: context)
- public API에 숨겨진 상호작용이 있는 경우
- 테스트
- 객체의 인스턴스화 및 테스트 작성이 복잡하고 어려운 경우
- 새로운 팀원이 클래스를 읽었을 때 빠르게 이해하기 어려운 경우
추가로
- 코드를 작성하는 동안 객체를 테스트하기 얼마나 어려운지 항상 생각해라
- 생성자에서
collaborators를 초기화하지 말고, 초기화가 완료된collaborators를 생성자로 받아라 단일 책임에 대한 동작을 캡슐화하는건 좋지만,책임간의 상호작용을 캡슐화하지 마라
잊지 말자
SRP,디미터법칙,DI
