도메인 관련
- 검증 로직의 위치는 어디?
도메인이 불완전한 상태로 생성 및 사용되지 않도록 검증 로직 위치를 정해야한다.
⇒ 도메인 검증은 도메인 객체가 직접!
⇒ 대부분 생성자에서 생성이 되므로 주 생성자에 검증 로직이 있는 것이 좋을 것 같다. - 비지니스 로직은 도메인에!
- 일급 컬렉션 보호
Collectors.toUnmodifiableList()=> add나 remove를 사용하면 exception - 주 생성자는 필드와 같은 자료형으로 받기
변환 등 로직 없이 객체를 완전히 초기화 할 수 있는 주 생성자를 만들고 부 생성자 고려 - 일급 컬렉션
일급 컬렌션이란? ⇒ Collection을 Wrapping하면서 그 외의 다른 멤버 변수가 없는 상태
쓰는 이유는? ⇒ 인스턴스의 집합을 Collection로 설정하게 되어, 단수형 클래스가 가질 수 없는 비즈니스 로직을 구현할 수 있도록 도와주는 도메인 설계
컨벤션 관련
- 나에게 맞는 구현 순서 정하기
상수 → 클래스 변수 → 인스턴스 변수
생성자 → 클래스 메서드 → 인스턴스 메서드 → getter, setter - 클래스 내부에서 사용하는 변수와 메서드는 private 접근 제어자!
네이밍 관련
- 효과적인 이름 짓기
오픈 소스나 다른 사람들의 코드 보면서 참고하기 - 메서드 이름은 구현과 관계없이 객체가 무엇을 하는지 생각하기
- 변수명에 타입 금지
타입이 바뀐다면 변수명까지 수정해야한다 - 클래스 이름과 중복되는 메소드명 X
ex) Car.moveCar 금지..
테스트 관련
- 테스트 생성의 기준
테스트 할 대상은 기능 목록에 대한 모든 테스트
모든 public 메소드 - @BeforeEach를 통해서 test 실행 전에 공통으로 실행할 로직 먼저 실행 가능
- 테스트를 위한 클래스는 테스트에!
- 인터페이스(특히 함수형), 문제가 되는 부분을 매개변수로 치환하여 테스트 하기 쉬운 구조로 변경할 수 있도록 생각해보기
뷰, 컨트롤러 관련
- 뷰는 언제든 변할 수 있으므로 뷰에 의존적인 코드 지양하기
뷰에 의존적인 리턴 값은 컨트롤러에서 변환 - 컨트롤러 내부에 상태 값 X
멀티스레드 환경 고려
그 외
- 구체적인 예외처리 하기
매개변수가 잘못 된 경우 ⇒IllegalArgumentException
매개변수의 상태가 잘못된 경우 ⇒IllegalStateException - 상수화 하여 중복 로직 제거
특히 유틸성 클래스 - 웹 요청 - 응답 구조 생각해보기
코딩하는 감자