자동차 경주 게임 피드백 영상 시청 후

테스트하기 어려운 부분을 찾아 가능한 구조로 개선

• Object Graph에서 다른 Object와 의존관계를 가지지 않는 마지막 노드를 먼저 찾는다.
• RacingMain -> RacingGame -> Car 같이 마지막인 Car를 먼저 한다.
• 또한 Car에 Random값에 의존성이 있다면 상위 Object로 올려서 하위 Object를 테스트 할 수 있도록 한다.
• getRandomNo 메서드를 protected로 변경 후 test코드에서 new Car {} 를 통해 override 해서 getRandomNo를 재정의하여 테스트도 가능하다. 하지만 장기적으로는 리팩토링을 통해 해결하자.
• 테스트는 경계값으로 하는것이 좋다. move가 되려면 4이상이라는 요구사항이면 3 과 4가 경계값
• 미리 예측을 하여 과도한 설계를 하지 않는게 좋을듯, 필요에 의해 리팩토링하자.
• 자주 변경될 가능성이 있는 부분은 인터페이스로 뺀다음 상속, override를 통해 리팩토링 가능하다. (Strategy 패턴으로 매개변수에 주입하여 해결가능 피트백에서는 MovingStrategy) 함수형 인터페이스로 만들어 람다로 줄일 수도 있으니 완전 놀랍
• 마지막에 DTO에 데이터를 전달 할 때는 getter, setter 있어야 되니 괜찮다. 하지만 도메인 객체는 만들지 않도록 하자.
• 객체지향에서 값가지고 비교하려고 하지말자, 객체끼리 비교하도록 하자.
• 불변(immutable)객체로 만들 경우 값을 안전하게 가지고 로직을 구현할 수 있다. 하지만 인스턴수 변수가 자주 발생해서 성능 저하가 우려 될 경우 mutable로 하는 것도 고려
• 마땅히 처음 테스트 코드를 작성할 것이 없으면 create로 생성자부터 만들어보자
• 명령과 조회를 분리하는 방법, 하나의 메서드로 처리하는 방법이 있다. 정답은 없다.
• 테스트를 위해 생성자를 추가하는 것도 방법이다. 혹은 Model과 DTO로 나누는것도 좋음
• 인스턴스 메서드로 테스트하기위해 생성자를 만들고 메서드를 테스트하는 것을 static메서드로 빼서 클래스 메서드로만 테스트도 가능하다는 점 잊지말자.
• View와 Model영역을 분리해서 하자, View성 클래스에 Model을 넣어서 print한다던가 하자