[우아한 테크캠프][PRO][3기] 1주차 정리 - 2

내가 구현하려던 것 : TDD 기반 프로그램

 

개인적으로 어려웠던 부분

• null return 에 대한 것을 의식하면서 진행 (아직 체득화되지 않음)
• final 키워드 잊지않고 적용
  (불변 객체로 만드는 것은 컴파일 시 이득뿐만 아니라 내부 상태가 변하지 않음이 결정되고 thread-safe 하기까지 하다!)
  • https://mangkyu.tistory.com/131#:~:text=%EB%B6%88%EB%B3%80%20%EA%B0%9D%EC%B2%B4%EB%8A%94%20%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9C%BC%EB%A1%9C,%EB%A5%BC%20%EB%8B%A4%EC%8B%9C%20%EC%82%AC%EC%9A%A9%ED%95%A0%20%EC%88%98%20%EC%9E%88%EB%8B%A4.
  • https://jackjeong.tistory.com/107

[Java] 불변 객체(Immutable Object) 및 final을 사용해야 하는 이유

[Java] First Class Collection(일급 컬렉션)

• 극단적 getter 제한 환경에서 Comparator를 위해서 getter를 만들기 보다는 Comparable을 이용해 정렬을 하는 것이 더 낫다!
  하지만 클래스 전체가 정렬 이용할 시 같은 기준으로 정렬 되는 것을 기억해야 함.
• 생각보다 view를 나눈다고 생각했었는데 많이 나누지 않았다. toString 특히 조심해야 할 녀석이다 ㄷㄷㄷ..
  toString을 이용해 구현해야 겠다고 생각한 순간 view에 필요한 로직들이 순식간에 불어나면서 domain 모델에 view 로직이 엄청나게 침투했다. 반성했다.
• 어떤 리스트의 일부만 가져올 때 subList는 매우 유용하다.
• 1단계 indent 이므로 코딩이 끝나고 한번 더 룰을 하나씩 체크하는 것이 정말정말 중요!
• Scanner는 nextInt() 와 같은 nextLine()이 아닌 것으로 받을 시 숫자를 누르고 enter를 누르면 다음번 nextLine()이 들어가 버린다. 이를 주의하여 코딩해야 함
• test 코드들 중 반복되는 코드들은 Fixture를 이용해 만드는 것도 좋은 방법!
• 변수명에 자료구조를 알 수 있는 map, ~list 와 같은 자료구조형 네이밍은 지양해야 한다. 변수명에서 캡슐화를 깨기 때문
• view에서 무언가 논리적 로직이 필요할 때 DTO를 이용하면 재밌게 만들 수 있다.
• DTO에서 필요한 것은 바로 당겨 쓸 수 있으므로 해당 객체를 받기보다 바로 integer 와 같이 받을 수 있는 것이 장점
• 그리고 DTO 만들기 전에 getter를 이용하는 것이 조금 그렇다면 도메인 객체 내부에서 toDto와 같은 것을 이용해 빌더 패턴을 만들고 이를 반환하여 DTO 생성 가능!!
• Fixture를 위해서 헬퍼 클래스를 만들고 이를 통해 만드는 방법이 있음 (매우 좋다고 생각함 리얼로!!)

느낀점

• 새벽에는 PR 보내지 않고 아침에 한번 더 확인하고 보내기 (여전히)
• 질문을 좀 더 많이 해야한다고 느꼈다. 미션을 빨리 수행하고 다 하기보다 제대로하고 많이 질문해서 제대로 얻어가자.
  (그래도 사람 욕심이 수료는 하고 싶은게 사람 욕심인가부다! ㅎㅎㅎ)

조언

질문에 대해 답을 드리자면

제가 DTO를 만들면서 기존에 너무 기계적으로 DTO를 생성 해 왔구나를 깨달았습니다. DTO를 만들면서 제가 기존 객체에 필요한 요소들을 가져오기 위해서 getter를 가져왔는데 이 부분에 getter를 사용하는 것은 괜찮을까요?

A) 네 그정도는 괜찮다고 생각합니다. 그럼에도 getter를 없애라고 했던 이유는 데이터를 DTO로 넘기기 위해 getter를 만들어뒀는데 로직에 사용하게 되는 걸 방지하는 차원에서 말씀드린거예요.

혹시 getter를 쓰지 않고 dto를 생성하는 다른 방법이 있으면 알려주시면 정말 감사하겠습니다 ㅠㅠ

A) Domain 내부에서 그 Domain의 필드값을 DTO 생성자 내부로 직접 넘겨주고 객체를 생성하여 DTO 객체를 반환하는 방법이 있겠네요, 빌더 패턴을 사용해서 반환하던가요.

e.g.

public class LottoNumber implements Comparable<LottoNumber> { ... private final int number; ... public LottoNumberDto toDto() { return new LottoNumberDto(number); } }

그런데 어떤 분들은 도메인 내부에 DTO에 종속적인 코드가 들어간다고 선호하지 않으시는 분들도 계셔요. 개인의 취향 차이라고 생각해요.
getter를 로직에서 활용만 안한다면 getter를 두어도 괜찮다고 생각합니다.(의도와는 다르게 어느새 getter를 사용하는게 문제지요ㅠ)

혹시나 static의 경우에 static으로 미리 등록해서 사용하는 경우, 다른 개발자가 본다면 더 헷갈릴 수도 있는 지 궁금합니다!

A) 저는 헷갈린다고 생각해 본적은 없는데, 만약 헷갈리신다거나 헷갈리는게 걱정 되신다면, 테스트 객체를 간편하게 만드는 헬퍼 클래스를 만드신 다던지, 그 객체에 생성자를 추가하시는 것도 방법입니다.

e.g.

LottoNumbers example = new LottoNumbers( Stream.of(new LottoNumber(1), new LottoNumber(2), new LottoNumber(3), new LottoNumber(4), new LottoNumber(5), new LottoNumber(6) ).collect(Collectors.toSet()));

위와 같이 LottoNumbers 객체를 생성하기 위해서

LottoNumbers example = Fixture.lottoNumbersOf(1, 2, 3, 4, 5, 6);

혹은

LottoNumbers example = new LottoNumbers(1, 2, 3, 4, 5, 6);

다만 헬퍼 클래스를 사용하고 싶으시다면 test 패키지 내부에 아래와 같이 만들어줘야겠죠

public class Fixture { private Fixture() {} public static LottoNumbers lottoNumbersOf(int... numbers) { return Arrays.stream(numbers) .mapToObj(LottoNumber::new) .collect(Collectors.collectingAndThen(Collectors.toSet(), LottoNumbers::new)); } }