[우아한 테크코스 8기 백엔드]프리코스 3주차 회고 -로또-

우아한 테크코스 8기 3주차가 종료됐습니다.

3주차의 미션은 7기의 3주차 미션과 같았습니다.

문제 링크는 아래와 같습니다.

 

https://github.com/woowacourse-precourse/java-lotto-8

GitHub - woowacourse-precourse/java-lotto-8

 

아래는 제출한 PR 주소입니다.

https://github.com/woowacourse-precourse/java-lotto-8/pull/101

[로또] 이재혁 미션 제출합니다. by LEEJaeHyeok97 · Pull Request #101 · woowacourse-precourse/java-lotto-8

 

3주차 로또 미션은 프리코스를 준비하기 위한 스터디를 운영하면서 시간을 재고 한번 풀어봤기 때문에 처음 미션을 봤을 때 이번 주는 미션을 해결하는 것에 목적을 두는 것 보다 학습목표를 최대한 달성하려고 노력하면서 특히, 객체지향적인 설계를 두고 많은 고민을 해야겠다는 마음으로 임했던 것 같습니다.

실제로도 도메인 설계와 객체간의 협력에 대해 고민하는데 대부분의 시간을 보낸 것 같습니다.

 

 

객체간의 협력에 대해 정의내리고 구현해보자

구현 전에 먼저, 객체들이 협력한다는 것의 정의를 명확히 내려야 했습니다.

2주차 까지 고민했던 부분에서 조금 더 나아가 보자고 생각하고 2주차 까지 고민했던 것을 되짚어봤습니다. ‘객체들은 상태와 행위를 가질 수 있고 객체들은 메시지를 통해 협력해야한다.’

 

따라서, “객체는 자기 자신에 대해서는 전문가가 되어야 하지만 외부는 몰라야 한다. 만약 외부의 객체가 해줘야할 일이 있다면 해당 객체의 행위를 호출해 메시지를 보내자’가 제가 정의한 객체들의 협력을 구현하는 방법이었습니다.

이를 위해 몇 가지 원칙을 정해야 했습니다.

 

첫 번째로 getter는 지양하지만 VO에서만은 getter를 허용하자. VO는 불변하고 고유한 값을 갖고 있고 이 값을 통해 뷰에 보여주거나 계산을 하는 값을 빼내 활용하는 부분이 어디든 반드시 필요했기 때문입니다. 또한, 값 자체를 다루는 객체기 때문에 값을 꺼내 보여주는 것도 적절한 역할이라 생각됐습니다 단, VO가 아닌 객체에서는 getter 를 사용하지 않았습니다.

 

두 번째, 각 객체의 역할에 부합하는 고유 전문적 일을 하는 메소드를 만들자. 예를 들면, Lotto 객체는 로또를 생성(발급)할 수 있는 일이 이 객체의 고유한 일이라고 생각했습니다. 나중에, LottoMachine 이나 Lottos같은 다른 객체에서 조금 더 자연스럽게 메시지를 받아서 이 발급하는 일을 처리하면 굉장히 아름다운 객체간 협력을 구현할 수 있겠다고 생각했습니다.

 

세 번째, 이렇게 객체를 각 분야의 전문가로 만들어 두고 다른 객체가 보내는 메시지를 받게 하자. 저는 Lottos라는 로또의 일급객체를 활용했기 때문에 로또의 묶음을 의미하는 Lottos에서 여러 장의 로또를 발급하는 행위가 있고 이 행위 안에서 Lotto에게 로또 한장 발급을 메시지로 말하는 방식으로 여러장의 로또 발급을 구현했습니다.

 

이렇게, 객체간의 협력을 구현하며 드는 의문은 A객체에서 B객체로 메시지를 보내면 같은 역할을 하는 메소드의 중복이 생기는게 아닌가? 하는 의문이 들었습니다. 이 부분이 미션을 진행하면서도 저를 답답하게 했던 부분이었습니다.

같은 일을 하는 메소드를 하나 더 추가하는게 뭐가 더 좋은 설계야? 라는 의문이 머리를 떠나지않았습니다. 그런데 객체 클래스들의 코드를 조금 더 들여다보며 깨달았습니다. 이건 단순한 중복이 아닌 경계를 의식적으로 한 겹 더 두는 선택이었습니다.

 

 

결국 이 한 겹의 위임은 게으름이 아니라 캡슐화를 지키기 위한 의도된 층 이라는 것을 이해하게 됐습니다.

 

 

enum을 사용하라는 추가된 구현 요구사항

실행결과의 로또 당첨 통계 출력을 보면서 각각의 등수 상태가 나뉘어져 있는 것을 보고 enum을 적용해볼 수 있지 않을까 생각이 들었습니다. enum이 사용 가능하다면 메소드를 활용하는 방법과 달리 관리 포인트가 명확하게 줄어들고 허용 가능한 값들을 제한할 수 있기 때문이었습니다.

 

특히, 상태와 행동을 한 곳에서 처리할 수 있다는 장점이 있습니다. 로또 등수를 계산할 때 만약 enum이 없다면 당첨 번호와 보너스 번호를 매칭 확인하는 메소드를 통해 계산 후 다른 객체로 전달해야 하지만 enum은 계산한 결과를 정해진 상수로 갖고 있기 때문에 계산한 결과를 상태로 가질 수 있어 값과 메소드가 어떤 관계가 있는지 enum 객체 안에서 찾을 수 있게 됐습니다.

코드 내에 전부 표현되어 있고 enum 객체에게 직접 물어보면 되기 때문입니다.

 

 

단위 테스트에 대한 나만의 기준을 세우자

 

위는 랜덤 로또 번호를 구현하기 위해 인터페이스를 의존하는 구조를 설명하기 위한 예시 그림입니다.

(상세 클래스명과 내용은 PR 코드를 확인해주세요!)

 

이런 구조 변화를 통해 Stub 클래스를 만들어 테스트할 수 없는 랜덤 뽑기 기능도 테스트할 수 있게 되는 효과를 얻을 수 있습니다..!

이와 같이 테스트하기 어려운 중요한 로직을 테스트할 수 있는 구조로 바꿔 가는 과정에서 코드가 조금 더 객체 간의 결합도를 낮추고, 책임이 분리되는 코드로 변화한다고 생각했습니다.

 

하나의 메소드가 너무 많은 일을 하고 있으면 테스트하기가 어렵고, 이 말은 테스트가 어렵다는 건 결국 설계가 좋지 않다는 신호라는 것을 미션을 통해 배울 수 있었습니다.

또한, 테스트를 작성하면서 ‘예외 상황’과 ‘경계값’을 빠뜨리지 않고 검증할 수 있었습니다.

 

 

느낀점

 

이번 8기의 미션들은 3주차까지 지난 7기의 미션과 완전히 같았습니다.

그렇기 때문에 우테코가 지원자에게 주고 싶은 메시지가 더 분명해졌다고 생각했습니다.

 

단순히 문제를 해결하는 것이 중요한 것이 아닌 미션 속에서 객체 간의 협력을 설계해보고 테스트하기 좋은 방법에 대해 고민해보는 시간을 준 것 같았습니다.

실제로 미션을 위해 주어진 일주일이라는 시간 동안 이전보다 훨씬 객체지향에 대한 이해와 테스트하기 쉬운 구조 설계에 대해 많은 고민을 하며 시간을 썼던 것 같습니다.

 

한 주 동안 미션 해결보다 객체지향적 설계의 효과를 체험하고 읽기 좋은 코드를 쓰기 위해 답이 없는 고민을 하는 과정에서 개발자로써 많이 성장할 수 있었습니다.

 

 

4주차에서도 3주차에서 배운 객체간의 협력이 좋은 설계를 만들어준다는 마음으로 임할 생각입니다..!