TDD 클린코드 with Java 16 기 3주차 회고

Good Point

• Java Lotto 기능 중 세부 기능인 문자열 계산기 에서 기존보다 개발 속도가 발라 졌으며 class 분리에 대한 감을 찾아가고 있는것같다.
• 기능 분리에 대한 감이 잘 오며 테스트 하기 어려운 부분또한 인터페이스 를 이용해 테스트 가능한 구조로 변경하면서 코딩을 하고 있다.

Bad Point

• 지난주보다 더 적은양의 시간이 투자되었다.

What I learned and What were reviewed

반복되는 구분이 있다면 테스트 픽스쳐를 사용하는 것을 고려해보자.

위와같은 부분에 대해 정리해놓은 블로그가 있었지만 이러한 구문을
테스트 픽스쳐 라고 명명되어있는것은 처음알게되었다.

테스트 픽스쳐

Getter 사용에 대하여

강의 전반에 걸쳐 Getter 를 사용하지 말자는 이슈가 존재한다. 이부분에 대하여 피드백을 받은 부분은

절!!대 !! 사용하지 말자 가 아니다. DTO 객체에서 즉 도메인 로직이 작용하지 않는 선에서는 Getter 메서드가 반드시 필요하다.

흔히 현업에서 Get 으로 값을 객체에서 직접 꺼낸후 Set 해 주는 로직이 매우 자주 발생하게 되는데 이러한 코드는 어디서 값이 변경되는지 찾기 어렵게 만들 뿐더라 캡슐화를 깨며 OOP 에 적대적인 코드이자 절차지향 적인 코드가 작성되게 된다.

final 로 선언한 불변 객체에 대하여

불변인 필드를 사용하고 있는 상태 즉 아래와 같은 상태일 경우

public class Car {
	public final Distance;
    ...
}

public class Distance {

	private final int distance = 0;
	...
}

위와같이 불변인 필드를 갖는 객체또한 불변성을 유지하는 것이 좋은 설계 이지만
리소스적인 면과 자주 상태값의 변화가 이뤄지는 컬럼이라면 반드시 레핑해주는 클래스까지 불변함을 유지하지 않아도 된다. 테스트만 가능하다면 꼭 반드시 지켜야 하는 룰은 아니나 지키려 노력하자.