프리코스가 끝나자마자 바로 회고를 작성하려고 했는데 다른 일들을 하다 보니 생각보다 늦어졌다. 예전 프로젝트 회고를 작성하면서도 느꼈지만 블로그 글 쓰는 것부터가 아직 서툴고 회고를 쓰는 데 생각보다 시간이 오래 걸리는 것 같다,, 많이 쓰다 보면 나아지겠지
\n2주차 미션이 끝나고 바로 3주차 미션이 시작되었다.
\n3주차 미션은 로또 게임 구현으로 이전 미션보다 기능 요구 사항이 많아졌고, 프로그래밍 요구 사항도 많아졌다.
필요한 흐름을 크게 4가지 단계로 나누고, 여기서 해당 단계에 필요한 기능과 예외 처리 부분들을 정리하는 방식으로 설계했다.
\n이 때 기능이 최소 단위가 되도록 더 나눌 수 있으면 분리하는 방식으로 진행하며, 이 후 구현 과정에서 하나의 함수가 정말 한 가지 기능만 담당할 수 있도록 했다.
2주차 미션 공통 피드백 중 하나로 함수가 한 가지 기능을 하는지 확인하는 기준을 세운다가 있었다.
기능 목록을 설계할 때, 가장 작은 단위로 기능을 분리하려고 했지만 그래도 여전히 더 분리할 수 있을 수도 있다.
\n이를 위해서 15라인 제한을 두었고, 구현 단계에서 만약 함수가 15라인을 넘어가면 기능 설계에 문제가 있었다는 것을 인지할 수 있도록 해 기능 분리와 함수 분리 연습에 많은 도움이 되었다.
2주차 미션 에서도 MVC 패턴에 가깝게 클래스 구조를 설계하려고 했지만 이 때는 MVC 패턴이 무엇인지 정확하게 모르고 있었기 때문에 이번 주차 미션에서는 MVC 패턴에 대해 공부한 후, 클래스 구조를 설계했다.
\n다음으로 클래스 구조 측면에서 바꿨던 점은 service 부분이다.
\n이전 주차 미션처럼 MVC 패턴 중 Model에 해당하는 부분을 domain 패키지와 service 패키지로 나누어 구현했다.
\ndomain 패키지에서 핵심 비즈니스 로직을 다루고, service 패키지에서는 비즈니스 로직에 필요한 작업들을 처리하도록 했다.
\n하지만 이번에 달라진 점은 domain에 맞춰서 service를 분리했다는 점이다.
\n이전 주차 미션에서는 비즈니스 로직에 대한 작업들을 처리하는 service 클래스를 하나만 만들어서 했지만, 이번 주차 미션에서는 domain 별로 나누어서 service 클래스를 만들었다.
\nservice를 도메인 로직에 맞춰 분리하여 구현하면서 보다 관리하기 편하게 했고, Controller 역할은 기능 범위가 크지 않아서 main에 있는 Application 클래스에서 담당하도록 했다.
마지막으로 domain 클래스에 값을 저장하는 방법도 바꿨다.
\n이전 주차 미션에서는 setter를 사용하여 값을 저장하는 방식을 사용했는데, setter를 사용하면 사용 의도를 알기 어렵고 값의 일관성을 유지하기 어렵다는 단점이 있다. 이런 이유 때문에 setter 사용은 지양하고 있고, 그래서 이번 주차에서는 생성자를 사용하는 방식으로 변경했다.
\nSetter 사용 지양과 관련해서는 추후 따로 포스팅할 예정이다.
2주차 미션에서도 단위 테스트 코드를 작성해서 테스팅을 진행했지만, 이 때는 정말 예제 코드를 따라서 몇 개 끄적여본 수준이었다.
\n이번에는 미션 목표에서부터 도메인 로직에 대한 단위 테스트를 작성하는 연습이라고 적혀있을 정도로 단위 테스트 구현에 대한 방향성이 제시되어 있었고, 그래서 이에 따라 구현하려고 노력했다.
우선 미션에서 주어진 기능 요구 사항을 읽고 전체 흐름을 먼저 정리했다.
\n그 다음, 정리한 전체 흐름을 바탕으로 필요한 기능 목록을 뽑아내고, 하나씩 순서대로 기능을 구현하고 테스트 코드를 작성하는 방식으로 진행했다.
기능을 미리 정해두고 맞춰서 구현해서 커밋하는 방식으로 하긴 했지만, 위에서도 보이는 것처럼 아직 기능이 가장 작은 단위로 분리되지는 않았고 유효성 검사에 대한 기능도 적은 상태다.
\n가령 위의 경우에서 입력받은 숫자와 컴퓨터 숫자 비교해서 볼, 스트라이크 반환하는 기능 같은 경우에는 숫자를 비교하는 기능과 볼, 스트라이크 반환하는 기능으로 나눌 수 있을 것이다.
이런 면에서 2주차 미션에서는 필요한 기능을 분리하려고 시도는 했으나,, 아직 완전히 만족스러운 형태로 작게 분리하지는 못해서 아쉬움이 남았었다,,
\n1주차 미션 공통 피드백 중 하나로 이름을 통해 의도를 드러낸다와 축약하지 않는다가 있었다.
기존 1주차 미션이나 평소 코딩 스타일에서도 메서드 명이나 변수 명으로 그 메서드와 변수의 역할을 드러내려고 했었는데, 이 피드백에서 집중했던 점은 축약하지 않는다였다.
평소에는 예를 들어, 사용자 상세 정보를 저장하는 변수면 userInfo로 변수 명을 정했었다. 당연히 이렇게 변수의 역할은 드러내면서 최대한 간결하게 이름을 작성하는게 좋다고 생각했기 때문에 이번 피드백은 많이 와닿았다.
\n피드백에서 원하는 대로 변수 명을 고친다면 userInformation이 될 것이다.
이름을 축약하는 게 당연하다고 생각했지만 사실 이것도 계속 긴 변수 명을 적기 싫었던 귀찮음에서 온 게 아닐까 다시 생각하게 됐다.
\n그래서 2주차 미션부터는 클래스 명, 메서드 명, 변수 명 전부 하나하나 신경써가며 이름을 지었다.
\n축약하지 않고, 최대한 그 역할을 드러내도록!
필요한 기능들을 정의하고 난 다음에는 전체 클래스 구조를 어떻게 설계할지 고민했다.
\n미션에서 요구하는 숫자야구 게임 자체가 복잡한 기능들이 필요한 게임이 아니기 때문에 간단하게 기능만 구현할까도 생각했지만, 오히려 간단한 기능들만 필요하다 보니 구조에 더 신경을 써야겠다고 생각했다.
이번 4주차 미션도 저번 주차 미션보다 기능 요구 사항과 프로그래밍 요구 사항이 많아졌다.
\n특히 함수의 길이가 15라인에서 10라인으로 타이트하게 줄어든 것을 볼 수 있고, 메서드의 파라미터 개수도 3개로 타이트하게 제한했다.
그리고 이번 4주차 미션의 전체적인 학습 목표는 다음과 같다.
\n위아래 둘 중 하나의 칸만 건널 수 있는 다리를 끝까지 건너가는 게임이다.
\nIllegalArgumentException를 발생시키고, “[ERROR]“로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다.\nException이 아닌 IllegalArgumentException, IllegalStateException 등과 같은 명확한 유형을 처리한다.…
\n다리 건너기 게임을 시작합니다.\n\n다리의 길이를 입력해주세요.\n3\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O ]\n[ ]\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O | X ]\n[ | ]\n\n게임을 다시 시도할지 여부를 입력해주세요. (재시도: R, 종료: Q)\nR\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O ]\n[ ]\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nD\n[ O | ]\n[ | O ]\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nD\n[ O | | ]\n[ | O | O ]\n\n최종 게임 결과\n[ O | | ]\n[ | O | O ]\n\n게임 성공 여부: 성공\n총 시도한 횟수: 2다리 건너기 게임을 시작합니다.\n\n다리의 길이를 입력해주세요.\n3\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O ]\n[ ]\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O | X ]\n[ | ]\n\n게임을 다시 시도할지 여부를 입력해주세요. (재시도: R, 종료: Q)\nQ\n최종 게임 결과\n[ O | X ]\n[ | ]\n\n게임 성공 여부: 실패\n총 시도한 횟수: 1지금까지 미션을 진행하면서 클래스 구조를 어떻게 하면 잘 설계할 수 있을지에 대해 많이 고민했다.
\n그래서 지금까지 MVC 패턴에 가깝게 미션에 맞는 클래스 구조를 설계했고, 마지막으로 4주차 미션에서는 비슷한 방식으로 설계하되 지난 주차 미션에서 아쉬웠던 점들을 보완하고자 했다.
4주차 미션에 추가된 프로그래밍 요구 사항에는 각 클래스 별로 제한 사항들이 많이 있었다.
\n그 중에서도 BridgeGame 클래스에서 InputView, OutputView 를 사용하지 않는다. 이 부분에 주목했다.
\n일단 저번 주차 미션에서 아쉬웠던 점 중 하나로 InputView 클래스를 만들지 않았다는 점이 있었다. OutputView 클래스는 구현했지만 InputView 클래스를 구현하지 않았었는데, 이번에는 InputView 클래스를 요구 사항에서부터 주었기 때문에 이 점은 쉽게 해결할 수 있었다.
\n하지만 지금까지 InputView, OutputView 클래스의 메서드들을 service 클래스에서 사용하고 Controller는 따로 구현하지 않는 방식으로 했었는데, 이번에는 요구사항에 BridgeGame 클래스에서 InputView, OutputView 를 사용하지 않는다. 이런 문구가 있어서 Controller와 Service를 확실하게 분리하여 구현하라는 말로 해석했다.
\n이전처럼 InputView, OutputView 클래스의 메서드들은 각 도메인에 해당하는 service 클래스에서 호출하여 사용하고, 하나의 BridgeGame이라는 Controller 클래스에서 각 상황에 필요한 service 메서드들을 호출하여 사용하는 방식으로 구현했다.
또한 이전 미션까지는 잘못된 값을 입력한 경우 IllegalArgumentException을 발생시키고, 에러 메세지를 출력한 후 종료하는 방식으로 예외 처리를 했었다.
\n하지만 이번 미션부터는 기능 요구사항에서 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, \"[ERROR]\"로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다.라는 방식으로 예외 처리 방식이 바뀌었다.
\n그래서 이 부분도 반복문 안에서 try-catch 문을 사용하여 예외 상황이 발생하면 계속 반복하는 방식으로 구현했다.
3주차 피드백을 보면 위와 같이 객체는 객체스럽게 사용한다라는 피드백이 있다.
\ngetter 사용해서 데이터를 직접 꺼내는 방식을 지양하고 메시지를 직접 던져주는 방식을 지향하자라는 피드백이다.
\n피드백으로 이전 주차 미션을 예시로 간단하게 코드를 통해 설명하고 다음의 참고 문서도 제공해주었다.
참고 : getter를 사용하는 대신 객체에 메시지를 보내자
\n해당 피드백에서는 이전 주차 미션을 예시로 간단하게 코드를 통해 설명해주었지만 메시지를 던져준다는 말이 어떤 방식인지 잘 이해가 되지 않았다. 그래서 위의 링크로 들어가 문서를 참고했다.
\n2주차 미션에서 3주차 미션으로 넘어오면서 setter를 사용하는 방식을 지양하도록 주의하며 구현했다. 하지만 getter 사용은 크게 문제가 되지 않을 거라고 생각했는데 그렇지 않았다.
\ngetter를 사용해서 데이터를 직접 주고 받는 방식을 사용하면, 이 또한 외부에서 값을 변경할 수 있다는 위험성이 조금이나마 생기게 된다.
\n이를 보고 피드백과 위 문서에서는 객체스럽지 못하다고 설명하고 있다.
또한, getter를 남용하면 디미터의 법칙을 위반할 가능성이 생긴다고 설명하고 있다.
\n디미터의 법칙은 다른 객체가 어떤 데이터를 가지고 있는지 서로 모르게 하여 객체 간의 결합도를 낮춰야 한다는 법칙이다.
\n그렇기 때문에 getter를 사용해서 데이터를 직접 주고 받는 방식보다는 필요한 메시지만 주고 받는 메서드를 만들어서 이를 호출하는 방식으로 구현해야 디미터의 법칙을 위반하지 않게 구현할 수 있을 것이다.
따라서 이번 미션에서는 최대한 getter를 지양하는 방향으로 주의하며 객체를 객체스럽게 구현하고자 했다.
\n이전 주차 미션에서도 Enum을 사용했지만 그 때는 처음 접하는 거라 어떤 상황에서 사용해야 하는지, 어떻게 사용해야 하는지 잘 모르는 상태로 사용했다.
\n그렇기 때문에 이번 미션에서는 Enum에 대해 정리된 여러 문서들을 참고해서 Enum에 대해 알아본 후 구현했다.
우선 이번 미션에서는 다리를 생성하기 위해 BridgeNumberGenerator를 사용하는데 여기서는 0과 1 중 랜덤한 정수 값이 반환된다.
\n그러면 이 정수 값들을 저장해서 생성된 다리 정보를 저장해야 하는데 처음 요구 사항에서 주어진 makeBridge 메서드의 반환 값은 List<String>이다.
\n따라서 랜덤 생성된 정수 값을 문자열로 반환해서 저장하는 과정이 필요했고, 이 과정을 Enum을 사용하여 해결하면 되겠다고 생각했다.
1이면 \"U\", 0이면 \"D\"로 반환해주면 됐기 때문에 이 값들을 각각 매핑해주고 필드 값들을 추가했다.
public enum Position {\n UP(1, \"U\"),\n DOWN(0, \"D\");\n\n private final int positionNumber;\n private final String positionValue;\n\n Position(int positionNumber, String positionValue) {\n this.positionNumber = positionNumber;\n this.positionValue = positionValue;\n }다음으로 이 positionNumber를 positionValue로 변환해주는 기능이 필요했는데, 다음과 같은 메서드를 만들고 stream을 이용해 값을 반환하도록 했다.
public static String convertNumberToValue(int number) {\n return Arrays.stream(Position.values())\n .filter(position -> position.positionNumber == number)\n .findAny()\n .orElseThrow(() -> new IllegalArgumentException(\"[ERROR] 0 또는 1의 값만 가능합니다.\"))\n .positionValue;\n}또한 게임의 성공 여부를 출력하는 부분에서도 불필요한 if문이 반복되어서 이를 해결하기 위해 Enum을 사용해야겠다고 생각해 리팩토링했다.
\nprivate static void printIsSuccess(boolean status) {\n if (status) {\n System.out.println(\"게임 성공 여부: 성공\");\n }\n if (!status) {\n System.out.println(\"게임 성공 여부: 실패\");\n }\n}위와 같이 status 불리언 값에 따라 출력 값이 달라지는 경우였다.
\n하지만 이렇게 if문을 나눠서 사용하는 것은 else 예약어를 사용하지 말라는 요구 사항에도 맞지 않다고 생각했고, Enum을 사용해 해결할 수 있을 거라 생각했다.
public enum Status {\n SUCCESS(true, \"성공\"),\n FAIL(false, \"실패\");\n\n private final boolean check;\n private final String message;\n\n Status(boolean check, String message) {\n this.check = check;\n this.message = message;\n }\n\n public static String convertCheckToMessage(boolean check) {\n return Arrays.stream(Status.values())\n .filter(status -> status.check == check)\n .findAny()\n .orElseThrow(() -> new IllegalArgumentException())\n .message;\n }\n}앞선 Position enum 클래스와 거의 비슷하게 Status enum 클래스를 만들고,
\nboolean 값을 String 값으로 변환해주는 메서드도 만들었다.
private static void printIsSuccess(boolean status) {\n System.out.println(\"게임 성공 여부: \" + Status.convertCheckToMessage(status));\n}이를 이용해 위에서 if문이 반복되어 문제가 되었던 코드도 한 줄로 깔끔하게 리팩토링 할 수 있었다.
\nOutputView에 단순하게 정해진 문자열만 출력하면 되는 메서드들이 있음(Enum을 사용하면 관리하기 보다 편할 것 같음)Collections.unmodifiableList() 같은 Unmodifiable Collection을 사용하자