[220305][JAVA] 로또 미션 리뷰 피드백을 통해 배운 점

2월 말부터 현재까지 2주동안 로또 미션을 진행했다.

로또 미션은 총 두단계로 나뉘어져 있으며, 

1단계는 로또(자동) 기능을 페어와 함께 구현하는 것이고,

2단계는 로또(수동) 기능을 혼자 추가하고 리팩토링하는 과정을 거치는 것이다.

 

이번 미션에서 리뷰어 던의 피드백을 받으면서 배우고 느낀 점을 적어보려 한다.

 

전체 리뷰 피드백 및 내 코드는 여기서 볼 수 있다.

https://github.com/woowacourse/java-lotto/pull/418

[2단계 - 로또(수동)] 케이(김태현) 미션 제출합니다. by kth990303 · Pull Request #418 · woowacourse/java-lotto

---

인터페이스를 활용한 추상화

로또(자동)과 로또(수동)의 공통점은 로또를 생성한다는 것이다.

리뷰어 던의 피드백 _ LottoRandomGenerator, LottoManualGenerator를 만들게 된 계기

이 기능은 어떤 요구사항이 오는지에 따라 변화가능성이 충분하며,

test에서 로또(자동)을 테스트하기엔 상당히 어렵기 때문에 test만을 위한 LottoCustomGenerator 클래스도 생성해줄 필요가 있었기 때문에 이 기능을 추상화하여 LottoGenerator 인터페이스를 만들 필요성을 느꼈다.

LottoGenerator 인터페이스

로또를 어떤 기능으로 만들든 상관없이, LottoGenerator 추상 타입의 generateLottoNumbersGroup() 메소드를 통해 로또를 생성해줄 수 있다.

service 입장에선, 로또를 어떻게 만드는지 상세한 구현을 알 필요 없고,

단지 로또를 만들어주라고 메시지를 던지고 로또를 얻으면 되기 때문에 이를 통해 캡슐화도 잘 지켜질 수 있다.

 

캡슐화 장점과 추상화 장점은 아래 글을 통해 볼 수 있다.

(호호스터디_ 객체지향과 디자인패턴 요약 포스팅이다.)

https://kth990303.tistory.com/274(캡슐화 장점)

https://kth990303.tistory.com/280(추상화 장점)

---

메소드의 역할은 최소화하자

그 전에는 생성자를 호출하기만 하면,

생성자에서 다른 클래스의 생성자를 호출해서 일부 로직을 실행하고, 검증도 진행하고, 상태 초기화도 진행하는 역할을 하였다.

LottoService의 생성자

service의 생성자에서

구입금액을 검증하고 상태를 초기화하는 역할,

구입금액에서 로또 개수를 얻어, 로또를 생성하는 역할,

로또 결과 상태를 초기화하는 역할을 진행하고 있다.

 

생성자의 역할 외에도, 비즈니스 로직이 굉장히 많이 들어가있는 상황이며,

LottoService 클래스의 상태도 적지 않아 초기화 또한 굉장히 많이 진행해주고 있는 모습이다.

상태가 많을수록 지나치게 역할이 많아 책임 분리가 잘 안돼있다는 반증이기도 하다.

 

이렇게 생성자에 많은 역할을 맡게 될 경우, 과한 의존성으로 인해 요구사항이 변경되거나 추가될 때, 변경에 유연하지 않아 고통받게 된다.

변경 후 생성자

지금은 생성자에서 Generator의 방법만 Controller에서 주입받도록 수정해주었다.

물론 현재도 문제점이 아예 없는 생성자라고 말할 순 없겠지만,

이전에 과하게 역할이 부여돼있던 생성자의 모습과 비교하면 훨씬 좋아진 모습이다.

---

Controller는 View와 Model 사이에서 데이터를 전달하는 역할

던에게 리뷰를 받기 전의 코드에선

controller가 데이터를 전달하는 역할은 거의 적었고, view와 service에게 메시지를 던지는 모습만 존재하였다.

메시지만 던지면 되지, 데이터는 왜 전달해야되는걸까?

 

controller에서 데이터를 던져주지 않을 경우,

service, 또는 view에서 상태를 불필요하게 많이 가지게 될 수도 있다.

controller에서 전달해줘야 할 데이터를, 전달해주지 않는 코드가 완성됐다면,

service에서 데이터 또는 상태를 너무 과하게 많이 가지고 있는 것이 아닐지 의심해보아야 한다.

변경 전 Controller 핵심 코드

피드백을 받기 전 controller의 핵심 코드이다.

데이터를 전달하는 모습이 거의 보이지 않는다.

전달한다 하더라도, output ui 클래스에게 일부 전달해주는 게 끝.

위에서도 언급했다시피, service에서 상태를 많이 가졌던 이유가 있다.

변경 후 controller 핵심 코드

피드백을 받은 후 변경한 controller의 핵심 코드이다.

service 로직을 이용해 데이터를 받고,

이를 다른 service 메서드의 파라미터를 통해 데이터를 전달해주는 모습이다.

가독성도 괜찮고, service 입장에서 controller에게 데이터를 전달받기 때문에 상태를 많이 가질 필요가 없어져 책임이 적어진다.

---

상태를 줄일수록 책임이 적어지고 클린해진다

위에서 계속 언급한 내용의 핵심이다.

피드백을 받고 수정하기 전, 내 코드에선 service가 과하게 많은 상태를 가지고 있었다.

이 말은 즉슨, service가 너무 많은 책임을 진행하고 있다는 말이고, 과한 의존성을 가지고 있단 소리다.

리뷰어 던의 피드백

불필요한 메서드가 존재한다면, 최대한 줄이고 상태도 줄이자.

또한, controller에서 데이터를 전달받는 방식으로 바꿔주면, domain에 과하게 의존할 필요 없이, 전달받은 데이터를 이용하기만 하면 되므로 이 문제점은 사라진다.

 

리뷰어 던의 피드백을 받기 전엔,

service에 존재하는 상태(인스턴스 변수) 개수가 5개였지만,

피드백 반영하면서 3개,

그리고 이어 반영하면서 2개로 줄일 수 있게 되었다.

 

피드백을 반영하기 전에는, 상태가 적을 때의 장점이 크게 실감나지 않았는데,

상태가 적을수록 각 메서드의 책임이 분리되고 전체적인 의존성도 줄어든 느낌이 들어 장점을 크게 실감할 수 있었다.

---

이번 미션을 통해서 객체지향적인 구조 설계에 대해 많은 생각을 할 수 있었던 좋은 기회였다 :)

구조뿐만 아니라, 크리스(페어)에게 배운 java api와 junit5 문법 지식도 많이 얻을 수 있었으며, 크리스와 설계 의견충돌, 변수명 의견충돌, commit message 의견충돌이 있을 때마다 얘기를 나누는 과정을 통해, 시야가 넓어지고 그 전에는 전혀 생각해보지 않았던 것들을 더 깊게 생각해보게 된 계기가 되는 시간이었다.

 

그리고 더욱 신기했던 건 이러한 경험을 겪고 나서,

객체지향과 디자인 패턴, 이펙티브 자바와 같은 추천도서들을 읽고 나니

전에는 당연하게 생각했던 내용들을,

지금은 오히려 더 많이 생각해보게 되고 깊게 이해할 수 있게 되었다.

이론과 실습이 병행될 때 확실히 학습효율이 높은듯.

 

확실히 코딩은 혼자서 공부할 때에도 많이 배우긴 하지만,

누군가와 협업하면서,

그리고 협업한 코드를 계속 봐주고 피드백해주는 리뷰어가 있을 때 훨씬 많이 성장하는 듯하다~!

 

다음 블랙잭 미션이 꽤나 어려워보이던데,

그 전까지는 추천도서를 읽거나, 푹 쉬거나 하여 체력을 충전해 놓아야겠다 ㅎㅎ