Today's Dev Notes(2018-10-25)

안녕하세요, Brad입니다. 오늘의 목표는 '로또' 미션 2단계 피드백을 적용하는 것이었습니다. 몇 가지 피드백이 있었는데요. 하나씩 살펴보도록 하겠습니다.

 

피드백1. 불필요한 DTO 제거

설계를 할 때 LottoChecker라는 클래스를 만들고 이 안에서 로또를 확인하는 작업을 이관하였습니다. 그곳에서 각 로또를 확인하고 그 결과를 넘겨줄 때 StrikeDto 를 별도로 만들었는데요. 이것의 필요성에 대한 의문이었습니다. 결국은 로또 확인을 LottoChecker로 이관했기 때문에 StrikeDto가 생긴거라 LottoChecker의 필요성과 밀접하게 관련이 있는 것이죠. 이와 관련된 처리는 피드백2에서 이어서 하겠습니다.

 

피드백2. LottoChecker 필요성

사실 LottoChecker클래스를 만들 때 이것의 필요성과 역할에 대한 고민을 하였습니다. 그런데 로직이 없으면서도 이것이 필요하다고 생각했던 이유는 뭔가 로또 체크에 관해 상징적으로 나타낼 수 있는 클래스가 있으면 좋겠다라는 저의 생각이 있었던 것 같아요. 하지만 그 로직이 없었고 그냥 값을 넘겨주는 중간 다리에 불과했기 때문에 그 필요성에 대한 의문을 제기한 것입니다. 결국 정리하면 다음과 같습니다.

• 그곳에서 하는 일이 LottoGame의 checkLotto()에서 충분히 처리가능
• LottoChecker에 로직이 없고 값을 전달하는 역할을 하는바엔 없는게 낫다
• 기존 rank와 rank개수를 넣어주는 assignGameResult() 역할을 LottoChecker에서 LottoChecker로 넘겨주는 일을 없애고 바로 결과를 받음으로써 checkLotto()에서 그 역할을 할 수 있음(assignGameResult()의 역할을 checkLotto()로 병합)

위 과정을 거치면서 코드에 대한 복잡도가 많이 줄어들었고 이것이 왜 필요한지에 대한 의문도 없어져 좋았습니다. 의미를 위한 의미를 부여하는 과정은 불필요했던 것 같습니다.

 

피드백3. 각 등수별 상금을 Rank에서 관리

기존에 상수값들을 한 클래스에 모두 모아 그곳에서 관리를 하였습니다. 그런데 등수별 상금 상수값에 관해서는 enum 클래스인 Rank에서 처리하는게 어떻겠는지에 대한 피드백이었습니다. 그 이유를 생각해보면 enum 역시 상수의 집합이고, Rank와의 연관성을 고려하면 enum클래스 내에 상금값을 관리하는게 좋다는 의견인 것 같습니다. 서로 연관된 것은 연관된 것끼리 가까이 둘 것. 최근 읽고 있는 '스프링 입문을 위한 자바 객체지향의 원리와 이해'의 객체지향 5대 원칙 부분에서 본 것 같은데 그 부분이 떠오르네요.

 

피드백4. 수익률 처리를 GameResult클래스에서 별도 처리

마지막 피드백은 'Map<Rank, Integer> gameResult을 인스턴스 변수로 가지는 GameResult 객체를 추가한 후 이곳에서 상금과 상금 비율을 구하는 로직을 만드는게 어떨까'라는 내용입니다. 이 내용이 처음에 잘 이해가 안가 물어보아서 다음과 같이 이해할 수 있었습니다.

• Map<Rank, Integer> 에 중요한 값이 들어있으니 이것을 인스턴스 변수로 만들고 그 클래스 안에서 수익률을 구하는 메서드를 만들어서 인스턴스 변수를 이용할 수 있다(이곳에도 상태값이 있는 곳에 그것을 이용하는 로직이 최대한 메서드로 구현되어 있을 것이라는 객체지향적 사고가 있습니다.)
• 출력View에 바로 그 새로 만든 클래스 GameResult를 보내줄 수도 있고 만약 이 안의 수익률 로직이 보이기 싫으면 Map과 수익률을 동시에 ResultDto로 보내서 이 ResultDto를 출력View로 넘겨줄 수도 있음

 

피드백4 부분은 Merge가 되고 난 후에 받은 피드백이라 다음 step에서 적용해봐야겠습니다!

오늘 추가적으로 공부한 부분

• 2018/10/25 - [Java] - 예외처리
• 2018/10/25 - [Algorithm/problem solving] - Today's Algorithm(2018-10-25)