[우테코] 프리코스 3주차

이번 주 과제는 로또 게임을 구현하는 것이었는데, 지난 주보다 구현해야하는 기능도 많아졌고, 지켜야 할 규칙도 늘어나면서 선뜻 시작하기가 어려웠다.

 

지난 주에는 코드를 작성하는 과정에서 출력 문자열을 상수로 이용하지 않고 그대로 하드코딩 했던 점과 예외 케이스를 놓쳤다는 점을 인지하면서 이번 주 과제에서는 같은 실수를 반복하지 않고자 했다.

 

배운 점

Getter 메서드 사용 최소화

외부에서 객체의 데이터를 받아 다르게 변형함으로써 객체 지향의 원칙 중 확장에는 열려있으나 변경에는 닫혀있어야 한다는 개방-폐쇄 원칙을 위반할 여지가 있기 때문에 getter 메서드를 최소화하려고 노력했다.

 

이전에도 getter 사용을 지양해야한다는 것을 들어본 적이 있지만, 당장 코드를 작성하는 데 급급했음을 핑계로 어떻게 준수해야할지에 대한 고민을 미뤄왔다가 적용해보게 되었다.

 

예를 들어, Lotto 클래스 내 private 접근 제어자를 가진 List 멤버 변수가 있을 때 해당 변수를 이용해 로직을 작성해야 한다고 가정해보자.

 

평소라면 private 멤버 변수를 반환하는 getter 메서드를 만들어 이용했겠지만, 대체할 수 있는 방법에 대해 고민을 해보았고 두 가지 방법을 적용하였다.

 

1. Collections.unmodifiableList()를 이용해 수정 불가능한 리스트 반환

클래스 내부에서 도저히 처리할 수 없다고 판단되었을 때 이용한 방법으로, List를 수정 불가능하도록 만든 뒤 반환함으로써 기존의 방법을 보완하고자 하였다.

 

2. getter 메서드를 private으로 변경하여 클래스 내부에서만 사용하도록 함

멤버 변수의 데이터를 이용해야하는 경우 해당 클래스 내부에서 작업을 처리하도록 메서드를 만듦으로써 외부로 데이터를 넘기지 않도록 하였다. 이렇게 변경하면서 멤버 변수가 속한 클래스의 메서드를 호출하다보니 외부 클래스의 코드 길이도 줄어들고, 클래스와 메서드 이름을 통해 어떤 로직이 수행되는지 쉽게 예측할 수 있는 장점이 있는 것 같다.

 

 

<수정 전>

private static int getRevenue(Map<WinningNumber, Integer> matchCount) {
    int sum = 0;
    for (WinningNumber winningNumber : matchCount.keySet()
            .stream()
            .sorted()
            .collect(Collectors.toList())) {
        sum += winningNumber.getMoney() * matchCount.get(winningNumber);
    }
    return sum;
}

<수정 후>

private static int getRevenue(Map<WinningNumber, Integer> matchCount) {
    int sum = 0;
    for (WinningNumber winningNumber : matchCount.keySet()
            .stream()
            .sorted()
            .collect(Collectors.toList())) {
        sum += WinningNumber.multiply(winningNumber, matchCount);
    }
    return sum;
}

위의 두 코드는 당첨 숫자에 따른 상금의 합계을 계산하는 코드이다. 상금과 당첨 횟수를 곱하여 그 금액을 구해 더하고 있다.

 

첫 번째는 상금을 구할 때winningNumber.getMoney() * matchCount.get(winningNumber)으로 작성했는데, getter를 이용해서 private 멤버 변수인 money의 값을 가져오고 있다.

두 번째는WinningNumber.multiply(winningNumber, matchCount)으로 수정한 것을 볼 수 있는데, WinningNumber 클래스에서 곱셈 연산을 한다는 것을 바로 알아볼 수 있다.

 

이렇듯 getter 사용을 줄이려는 것 뿐이었는데, 그 과정에서 의도치 않게 리팩토링을 경험하게 되었고 습관적으로 코드를 작성하기보다 항상 좋은 설계에 대해 생각하면서 코드를 작성해야겠다는 배움을 얻을 수 있었다.

 

한 메서드는 하나의 역할만

프리코스를 시작했을 때부터 지키려고 했던 부분이지만, 코드를 작성하는 과정에서 하나의 역할을 구분짓는게 모호해지면서 준수하기가 쉽지 않았던 부분이었다.

 

이 원칙을 체감할 수 있었던 계기는 테스트 코드를 작성하면서였다. 테스트 코드를 기능별로 구성하는 것도 고민이 많았었는데, 가장 고민이 많았던 부분은 Scanner로 사용자의 입력을 받는 메서드는 어떻게 테스트를 작성해야 할지에 관한 것이었다.

 

메서드 내부에서 사용자의 입력을 받기 때문에 junit의 기능으로 테스트를 구성하는 것은 힘들다고 판단하였고, 설계 자체에 대해 의심을 해보기 시작했다.

 

고민을 하던 중 '어차피 Scanner로 받는 것도 변수에 담아 작업을 처리하니까, 메서드를 실행하기 전 사용자의 입력을 받아서 한 번에 매개변수로 넘기면 되지 않을까'라는 생각이 들었고, 오직 입력만 받는 메서드를 만든 뒤 리턴 값이 곧 매개변수로 넘어가도록 분리하니 테스트 코드를 수월하게 작성할 수 있었다.

 

이러한 경험을 통해 기존에 구현한 메서드는 여러 역할을 가지고 있음을 깨달을 수 있었고, 한 메서드가 하나의 역할만 수행한다는 원칙의 장점을 깨달을 수 있었다.

 

 

고민했던 부분 & 보완할 점

패키지 구성

피어리뷰를 하다보면 한 패키지에 이것저것 다 넣은 내 과제와 다르게 여러 디자인 패턴을 적용한 모습을 많이 볼 수 있었다. 확실히 그렇게 설계를 해놓으니 코드를 읽으면서 이해하기도 좋고 구성이 깔끔해보였다.

 

리팩토링 과정에서 패키지 구성을 바꿔볼까 생각했지만, 그렇게 했다가는 아예 갈아엎어야할 것 같아서(..) 다음 주 미션에는 MVC 패턴을 적용해 구현해보는 것을 목표로 하고 있다.

 

상수 선언 위치

여러가지 상수를 만들면서 고민이 됐던 부분이 있는데, 아예 상수만을 정의하는 클래스를 만들어 한 번에 몰아서 넣는게 좋은 것인지, 아니면 특정 클래스 내부에서 선언해 사용하는게 좋은 것인지 확신이 서지 않는다.

 

만약 특정 상수가 여러 클래스에서 중복적으로 쓰이는 것이라면 전자의 경우가 더 나을 것 같기는 한데, 특정 클래스에서만 쓰이는 상수라면 굳이 상수 클래스를 만들어 포함을 시켜야하나라는 생각이 든다. 이 부분은 더 학습을 하면서 알아봐야할 것 같다.

 

인자 호출 방식

메서드 A를 호출할 때 인자로 들어가는 값이 메서드 B의 리턴값이라면 다른 임시 변수에 메서드 B의 리턴값을 받아두었다가 A의 인자에 해당 임시 변수를 넣을 것인지, 아니면 메서드 A의 인자에 메서드 B를 바로 호출하는 식으로 코드를 작성할지가 고민되었다. 전자의 방식이 더 적절할 것 같기는 한데, 그 이유에 대해 더 공부해봐야겠다는 생각이 들었다.

 

 

 

미션을 진행하면서 초기 주차에는 자바가 가지고 있는 여러 기능(메서드 혹은 클래스)을 활용하는 방법에 대한 배움이 더 많았다면, 후반으로 올수록 그보다는 객체 지향적 설계에 관한 고민과 깨달음으로부터 얻는 배움이 더 커지는 것 같다.

 

마지막까지 새로운 배움을 얻어갈 수 있도록 열심히 고민해봐야겠다는 생각이 들었다.