0. 전파를 최대한 줄이자...
1. 캡슐화 규칙
1. Tell, Don't Ask
- 객체에게 데이터를 달라 하지 말고 해달라고 하기
2. Demeter's Law
- (생성한/파라미터로 받은/참조하는) 객체의 메서드만 호출하기
+ chaining 지양...
//bad1
acc.getExpDate().isAfter(now);
//bad2
Date date = acc.getExpDate();
date.isAfter(now);
//good
acc.isValid(now)
2. 다형성과 추상화
1. 추상화 시점
- 미리 예상해서 추상화하면 복잡도 증가, 잘못된 추상화 가능성 다분
- So, 실제 변경, 확장 등이 발생할 때 시도
3. 상속보다 조립
- 조립 : Class in Class 개념 생각하면 될 듯
4. 기능과 책임 분리
- 기능을 하위 기능으로 쪼갠 뒤,
- 각 기능을 어떤 객체가 제공할 것인지 책임을 분배
5. 의존과 DI
1. 의존 대상이 많으면...
- 테스트 코드 작성이 힘듬
- 특정 메서드 테스트 때 다른 메서드의 의존 대상도 주입해야 하므로
6. DIP
- 의존 역전 원칙(Dependency Inversion Principle)
- 저수준 모듈이 고수준 모듈에서 정의한 추상타입에 의존해야 함
//고수준 모듈 : MeasureService
public class MeasureService {
public void measure(File file) {
//저수준 모듈 nasStorage의 method를 직접 호출할 경우
nasStorage.save(file);
//저수준 모듈이 바뀔 경우 고수준 모듈의 메서드가 변경되는 상황이 발생
//s3Storage.upload(file);
}
}
- So, FileService라는 추상타입을 중간에 넣어,
- NasStorage나 S3Storage는 FileService를 구현,
- MeasureService는 FileService의 save를 호출