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

우아한 테크코스 프리코스 3주차가 끝났습니다.

이번 3주차 미션은 로또 미션 이었습니다.

GitHub - woowacourse-precourse/java-lotto-7

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

[로또] 이동엽 미션 제출합니다. by dye0p · Pull Request #198 · woowacourse-precourse/java-lotto-7

3주차 문제는 로또 문제였습니다! 3주차 미션부터 이제 조금씩 기능 요구사항이 복잡해졌습니다. 추가로 프로그래밍 요구사항도 함께 추가되어서 신경쓸 부분이 정말 많았습니다.

1. 함수형 인터페이스

지난 2주차 자동차 경주 미션에서 자동차들의 이동 전략을 인터페이스를 이용해 전략패턴을 사용하여 테스트가 용이하도록 구현하였습니다. 2주차 미션의 회고는 여기서 확인할 수 있습니다.

자동차의 이동 조건인 랜덤값을, 프로덕션 코드에서는 실제 랜덤값을 생성하는 구현체를 사용하도록 외부에서 의존성 주입을 해주었고,

테스트를 할때엔 임의로 랜덤값을 지정해주어야 하기 때문에 테스트를 위한 가짜 객체인 Stub 구현체를 사용하였습니다. 

 

예시를 위해서 2주차 미션의 코드를 잠시 가져오겠습니다!

생성자를 통해서 받은 숫자를 그대로 리턴하는 stub 객체

Stub 객체를 이용한 랜덤값 테스트

이렇게 2주차 미션에서는 Stub 객체를 이용해서 테스트를 하였습니다.
이번 3주차 미션에도 동일하게 로또 번호를 생성해야하는. 랜덤값을 다뤄야 하는 조건이 있었습니다. 이전과 동일하게 Stub 객체를 생성할까 했지만 Stub 객체를 생성하지 않고, 테스트를 할 수 없을까에 대한 고민을 하게 되었고, 자바 8의 함수형 인터페이스 표현방식으로 Stub 객체를 대체 할 수 있다는것을 알게 되었습니다.

(* 함수형 인터페이스에 대해서 정확하게 아는것이 아닙니다. 혹시나 틀린 부분이 있다면 지적해주시면 감사하겠습니다😊)

 

자바 8부터 도입된 함수형 인터페이스는 추상 메서드가 오직 하나인 인터페이스를 말합니다.

하나의 추상 메서드만을 가지는 이러한 인터페이스를 함수형 인터페이스라고 합니다.

원래는 @FunctionalInterface 어노테이션으로 함수형 인터페이스임을 명시해주어야 하지만 직접적으로 명시해주지 않아도 추상 메서드가 하나만 있다면 함수형 인터페이스로 간주됩니다.

 

이러한 함수형 인터페이스를 람다식을 이용하여 간단한 Stub 객체를 대체할 수 있습니다.

Stub 객체를 사용하는것이 아닌 함수형 인터페이스를 람다식으로 표현하여 Stub 객체를 대체했습니다.

위 사진처럼 Stub 객체를 직접 구현하지 않고 함수형 인터페이스를 람다식으로 표현하여 로또 번호를 임의로 생성해주었습니다. 기존의 Stub 구현체를 생성하고, 메서드를 오버라이딩 하지 않고 간단하게 이를 표현하였습니다.

 

하지만 함수형 인터페이스를 사용하는것이 Stub 객체를 완전히 대체하는것은 아닙니다. 함수형 인터페이스는 Stub 객체를 간소화 하는 것에 가깝고, 필요에 따라서는 Stub 객체가 필요할 수 있습니다.

 

2. Enum 클래스의 사용

새롭게 추가된 요구사항으로 "Java Enum을 적용하여 프로그램을 구현한다." 라는 요구사항이 추가되었습니다.

지금까지 Enum 클래스는 예외메세지를 상수화 시켜 보관하는 용도로 사용했습니다. 그래서 Enum 클래스에 대해서 잘 몰랐습니다.

미션을 진행하면서 Enum 클래스에 대해서 공부를 했고, 활용방법을 조금은 알게 되었습니다. Enum 클래스의 활용 과정에 대한 정리는 여기서 얘기하면 너무 길어질것 같아 노션에 따로 정리한 링크를 첨부하겠습니다!

16,17일차 Enum의 활용 | Notion

개인적으로 정리를 하면서 많은 도움이 되었던 우아한 형제들의 기술블로그 아티클 입니다!

Java Enum 활용기 | 우아한형제들 기술블로그

3. 정적 팩토리 메서드의 쓰임

2주차 코드리뷰에서 감사하게도 6기 크루분께서 리뷰를 남겨주셨습니다. 리뷰중 정적팩토리 메서드에 대한 피드백이 있었습니다.

지금껏 객체를 생성할때 정적 팩토리 메서드를 무의식 적으로 사용했습니다. 해당 피드백을 보고 정적 팩토리 메서드가 꼭 필요한 이유가 무엇인지 생각해보았습니다. 그래서 내린 결론은 생성자에 유효성 검사 등과 같은 별도의 로직이 없다면 굳이 정적 팩토리 메서드를 사용할 필요가 없다고 판단했습니다. 위의 피드백처럼 인스턴스를 생성하기 위해서는 어쩔수 없이 외부에서 노출될 수 밖에 없고, 단지 생성자를 리턴 해주는 역할만을 하는 정적 팩토리 메서드는 굳이? 라고 생각이 들었습니다. 하지만 이 부분도 분명 적절하지 못한 판단일 수 있습니다. 추후에 점점 공부를 해가며 알아가 봐야할것 같습니다. 그래서 이번 미션을 진행할때는 단순히 생성만 하는 로직이라면 정적 팩토리 메서드를 구현하지 않고, 외부에서 생성자를 사용하였습니다. 추가로 객체의 생성 테스트 코드 작성시 별도의 유효성 검사가 필요한 객체의 생성만 테스트를 진행해 주었습니다!

 

느낀점

3주차 미션부터 아쉬운 부분들이 많이 생겼습니다. 미션을 완성하고 보니 설계했던과는 다르게 컨트롤러에 많은 객체들이 의존하고 있는 것을 알 수 있었습니다.

컨트롤에서 의존하고 있는 의존성

설계의 중요성을 깨닫게 되었고, 미션의 난이도가 올라고, 요구사항이 점점 붙음으로서 원했던 객체지향 설계가 힘들었습니다. 코드를 구현하고 있으면 무의식적으로 절차지향적으로 설계하고 있는 자신을 발견할 수 있었고, 이것은 의식적으로 고쳐나가야 된다고 느꼈습니다. 

이외에도 유효성 검사, 클린코드 등등 신경쓸것이 많은것에 부담을 느끼기도 했습니다.(아직 한참 멀었구나..) 

 

모르는 것이 많다보니 미션을 진행하면서 알게되는것이 정말 많습니다. 배운것을 모두 체화하려면 많은 시간이 걸리겠지만 즐거움 마음으로 임하려고 합니다. 벌써 프리코스의 3주차가 지나가고 한 개의 미션만 남게 되었습니다. 시작만큼 마무리도 중요하다고 생각이 듭니다. 지금껏 잘 해온 만큼 아름답게 마무리 되었으면 하는 바램입니다. 3주차 미션을 진행한 모든 지원자분들 수고 많으셨습니다 :) 감사합니다!