[우테코 최종코테준비] 6기 프리코스 1주차 야구게임 리팩토링

오늘은 야구게임 리팩토링을 진행했다

 

리팩토링을 하면서 생각나는 것들이랑 추가해 볼 것들을 적어봤는데

• outputView는 무조건 컨트롤러에서 해야하나? -> 당연
• 컨트롤러는 딱 입력 -> 서비스 -> 출력임
• 여기서 서비스는 컨트롤러에서 반환하면서 의미있는 객체 즉 dto를 사용하면 더 좋음
• 현재 GameService.playOneGame()이 List<Integer>를 반환하면, 이 리스트의 첫 번째 요소가 볼(Ball)인지, 스트라이크(Strike)인지, 아니면 다른 의미인지 코드를 분석해야만 알 수 있습니다. -> 지피티 답변
• 컨트롤러 안에서 돌아다닐 데이터를 정해보자
• dto 클래스에서의 책임은 어디까지인가?

---

 

리팩토링을 하면서 dto라는 것을 솔직히 지금까지 무슨의미인지 잘 몰랐는데

오늘 조금 의미가 와닿아서 수정을 같이 진행 했다.

 

프리코스에서 지금까지 쭉 문제를 풀면서 서비스에서 컨트롤러로 반환을 할 때

나는 단순히 리스트나 값을 반환하는 방식을 썼었다. 

 

하지만 이번에 내가 짠 야구게임 코드는 

리스트 [ 스트라이크 갯수, 볼 갯수, 낫싱 갯수]

이렇게 리스트를 만들어서 갯수를 반환하면서 컨트롤러 내부를 돌아다녔는데 돌아 다닐 때마다

이 리스트를 받는 메서드는 계속 리스트 내부를 확인해야 하는 번거로음이 있다는 것을 처음 알았다!!

 

그래서 dto 데이터 전송만하는 객체를 만들어두면 번거롭게 확인하지 않는 의미있는 객체를 반환하게 된다는 것을 알았다.

그리고 dto는 단순히 데이터 구조이지 의존성 주입 대상이 아니라는 것을 꼭 기억하자

 

---

 

그리고 컨트롤러에 대해 나는 흐름이라는 것만 알고 정확히 어떤 흐름만 가지는지 잘 인지하지 않고 코드를 짰는데

오늘로서 확실히 기준이 정리가 되었다.

컨트롤러는  입력-> 서비스, 서비스, 서비스 -> 출력 이런 흐름임을 꼭 기억하면서 코드를 짜보자 

---

그리고  리팩토링 하기 전에 내 코드에서 ResultGame은 세 가지 역할을 하고 있었다. 

1. 결과를 출력하는 역할 (output 필드와 함께 사용).
2. 게임 종료 여부를 판단하는 역할 (gameResult() 메서드).
3. 컨트롤러 내에서 생성되는 역할.

 이 부분을 분리하기 위해  결과출력은 outputView로 빼는데

게임 종료여부 판단은 어디로 분리를 시켜야하는지 애매했다.

 

애매한 부분을 재미나이한테 물어보니 dto객체한테 넘겨주라는 것이 었다.

엥..  dto는 단순히 데이터 전송만 하는 객체가 아니었나?.. 

 

BaseballScore는 DTO 클래스이지만, 게임 종료 판단 책임을 가지는 것이 현재의 아키텍처 방향성에는 더 적합합니다.
일반적인 DTO(Data Transfer Object)는 순수하게 데이터만 전달하는 역할을 하지만,
현재의 상황에서는 BaseballScore를 값 객체(Value Object, VO)의 성격도 가지도록 설계하는 것이
컨트롤러의 복잡성을 낮추고 책임 분리를 명확히 하는 데 핵심적인 방향성입니다.

 

이렇게 답변이 왔다.

이에 따라서 왜 dto에 책임을 부여하는지 알려줬는데

 

높은 응집성과 DTO/VO의 현대적인 역할 두가지 이유를 알려줬는데

 

게임 종료 판단은 dto내부에 스트라이크 카운트 멤버변수에 전적으로 의존을 한다 당연히 스트라이크가 3개면 종료되니까

그리고 최근 객체지향 설계에서 DTO/VO의 경계를 유연하게 가져간다고 한다

 

따라서 단순한dto 대신 게임 점수라는 값의 의미를 온전히담을 뿐아니라 그 값에 기반한 판단책임까지 설계하는게 가독성과 유지보수가 좋다라는데 

 

이 부분은 좀 더 공부해봐야 할 것 같다. 확신이 잘 안선다 

 

---

 

오늘은 많이 못했다.. 진짜 집에 있으니까 공부를 몬하겠네 ㅋㅋ

나가고 싶지만 밖이 너무 추운걸;;

 

내일은 지하철 문제 꼭 풀어보자