[우아한테크코스 6기] 프리코스 4주차 크리스마스 프로모션 미션 후기

길었던 4주간의 프리코스가 끝이 났습니다. 마지막 주차는 크리스마스 프로모션 미션으로 3주차 로또 미션과 비슷하되 확장된 맥락의 미션이었는데요. 간단하게 이번 주차에 적용하고 개선하고 고민한 점들을 리뷰해보고자합니다.

---

🚩4주차 목표

• 우선 저는 이번 미션에서는 다음과 같은 목표를 두었습니다.

1. 요구사항이 많아진 만큼, 명세서 꼼꼼하게 확인하고 구현하기
2. 객체를 객체스럽게 사용하기
   1. 도메인과 도메인 사이 의존관계를 두지 않기
      1. 객체 생성에 다른 도메인의 값이 필요한 경우 메시지를 통해 연결고리를 만들어 생성함으로써, 응집도를 낮추자.
   2. getter 지양, TDA(Tell, Don't Ask) 원칙 적용 : 객체가 할 수 있는 일은 객체에게 물어보지 않고 시키도록 하자. 
      1. 객체가 할 수 있는 일이라 함은 객체의 필드값에 대한 핸들링(검증, 계산)
      2. View에서 부득이하게 객체의 필드값을 출력해야 하는 경우를 제외하고 getter를 사용하지 않도록 하기.
3. 네이밍에 조금 더 신경쓰기
   1. 의도를 해치지 않음과 동시에 한 눈에 알아볼 수 있는 키워드 중심으로 작명하자.
4. 최종 코딩 테스트에서 시간 내에 구현할 수 있는 코드를 만들자.
   
   1. 비즈니스 확장성을 고려해 현재 사용하지 않는 코드에 대해 불필요하게 볼륨을 키우기보다, 최종 코딩 테스트에서 내가 구현할 수 있는 코드를 구현하자. 
   2. 무리한 확장은 가독성을 저하시킬 우려가 크다. 확장성을 고려할 시간에 차라리 객체지향설계에 힘을 쏟자.

---

프로그래밍 요구사항과 기능 요구사항을 정리하면 다음과 같습니다.

 

🚩프로그래밍 요구사항

➡️ 추가된 요구 사항

• 아래 있는 `InputView`, `OutputView` 클래스를 참고하여 입출력 클래스를 구현합니다.
  • 입력과 출력을 담당하는 클래스를 별도로 구현합니다.
• 해당 클래스의 패키지, 클래스명, 메서드의 반환 타입과 시그니처는 자유롭게 구현할 수 있습니다.

public class InputView {
      public int readDate() {
          System.out.println("12월 중 식당 예상 방문 날짜는 언제인가요? (숫자만 입력해 주세요!)");
          String input = Console.readLine();
      }
  }

public class OutputView {
  public void printMenu() {
      System.out.println("<주문 메뉴>");
      // ...
  }
  // ...
}

---

🚩기능 요구 사항 정리

➡️ 메뉴

<애피타이저>
양송이수프(6,000), 타파스(5,500), 시저샐러드(8,000)
<메인>
티본스테이크(55,000), 바비큐립(54,000), 해산물파스타(35,000), 크리스마스파스타(25,000)
<디저트>
초코케이크(15,000), 아이스크림(5,000)
<음료>
제로콜라(3,000), 레드와인(60,000), 샴페인(25,000)

➡️ 할인

중복된 할인 + 증정으로 이벤트 기간 : '디데이 할인'을 제외한 모든 이벤트는 12월 1일 ~ 31일까지 적용한다.
1. 디데이 할인 : 1000원으로 시작해서 할인금액이 100원씩 증가한다.
        - ex) 12월 1일 1000원, 2일에 1100원, 25일엔 3400원
            - 이벤트 기간 : 할인은 12월 1일부터 25일까지
2. 평일 할인 (일요일~목요일) : 디저트 메뉴를 메뉴 1개당 2023원 할인
3. 주말 할인 (금요일,토요일) : 메인 메뉴를 메뉴 1개당 2023원 할인
4. 특별 할인 : 이벤트 달력에 별이 있으면 총 주문 금액에서 1000원 할인
5. 증정 이벤트 : 할인 전 총 주문 금액이 120,000원인 경우 ▶︎ "샴페인 1개" 증정

➡️ 배지

총 혜택 금액이 5000원 이상 ▶︎ "별" 배지 증정
총 혜택 금액이 1만원 이상 ▶︎ "트리" 배지 증정
총 혜택 금액이 2만원 이상 ▶︎ "산타" 배지 증정

➡️ 주의 사항

• 총 주문 금액 10,000원 이상 부터 이벤트를 적용합니다.
• 음료만 주문 시 주문이 불가능합니다.
• 메뉴는 한 번에 최대 20개까지만 주문가능합니다.
  • (e.g. 시저샐러드-1, 티본스테이크-1, 크리스마스파스타-1, 제로콜라-3, 아이스크림-1의 총개수는 7개)

➡️ 출력

• "12월 중 식당 예상 방문 날짜는 언제인가요? (숫자만 입력해 주세요!)"
  •  방문할 날짜는 1 이상 31 이하의 숫자
  •  1 이상 31 이하의 숫자가 아닌 경우, "[ERROR] 유효하지 않은 날짜입니다. 다시 입력해 주세요."라는 에러 메시지 출력
• "주문하실 메뉴와 개수를 알려 주세요. (e.g. 해산물파스타-2,레드와인-1,초코케이크-1)"
  •  메뉴판에 없는 메뉴를 입력하는 경우, "[ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요."라는 에러 메시지 출력
  •  메뉴의 개수는 1 이상의 숫자만 입력되도록 해주세요. 이외의 입력값은 "[ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요."라는 에러 메시지 출력
  •  메뉴 형식이 예시와 다른 경우, "[ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요."라는 에러 메시지 출력
  •  중복 메뉴를 입력한 경우(e.g. 시저샐러드-1,시저샐러드-1), "[ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요."라는에러 메시지 출력
• 주문 메뉴 출력
  • 순서는 자유롭게 출력 가능
• 할인 전 총 주문 금액 출력
• 증정 메뉴
  •  할인 후 예상 결제 금액(할인 전 총주문 금액 - 할인 금액)이 120,000원 이상인 경우 "샴페인 1개" 출력
  •  증정 이벤트에 해당하지 않는 경우, 증정 메뉴 "없음"으로 출력
• 혜택 내역
  •  적용된 이벤트 내역’만’ 출력
  •  적용된 이벤트가 없다면 혜택 내역 "없음"으로 출력
  •  혜택 내역에 여러 개의 이벤트가 적용된 경우, 출력 순서는 자유롭게 출력가능
• 총혜택 금액(할인 금액의 합계 + 증정 메뉴의 가격) 출력
• 이벤트 배지
  • 총혜택 금액에 따라 이벤트 배지의 이름을 다르게 출력
  • 이벤트 배지가 부여되지 않는 경우, "없음"으로 출력

---

🚩 입력값 파싱

방문 날짜에 대한 입력은 InputValidtor에서 숫자 입력에 대한 검증을 마친 후 VisitDay라는 Value Object(이제부터 줄여 VO라고 칭하겠습니다)를 생성하되, 생성자에서 비즈니스 로직과 연관된 검증을 수행하고 검증에 통과하면 정상적으로 생성자가 동작하고, 통과하지 못하면 커스텀한 RuntimeException을 던지도록 구현하였습니다.

public VisitDay {
    validate(day);
}

private void validate(final Integer day) {
    if (!isInMonth(day)) {
        throw new InvalidValueOfDayException();
    }
}

private boolean isInMonth(final Integer day) {
    if (day >= START_DAY_OF_MONTH && day <= END_DAY_OF_MONTH) {
        return true;
    }
    return false;
}

 

 

주문에 대한 입력은 "시저샐러드-1, 티본스테이크-1, 크리스마스파스타-1, 제로콜라-3, 아이스크림-1"와 같이 각 메뉴는 ","로 분리하고 메뉴에 대한 수량은 "-"으로 분리해야 합니다. 

1. String을 ","을 기점으로 슬라이싱

• 우선 ","을 기점으로 입력받은 String을 슬라이싱하하여 주문의 "메뉴-수량"을 String 형태로 List Collection에 저장하였습니다.

 

2. "-"을 기점으로 슬라이싱하여 Map에 삽입

• 1번 과정을 통해 저장한 List<String>을 stream하여 "-"을 기점으로 슬라이싱하여 각각의 필드값을 통해 VO를 만들었습니다.

 

3. VO로 만들어진 객체들을 Map에 삽입

2번 과정을 통해 슬라이싱한 String 값들을 Map에 VO(Food와 Quantity)를 담아주었습니다.

 

• 만들어진 Map의 정보를 토대로 주문 클래스의 객체를 생성하여 사용하였습니다.
• Order 클래스는 비즈니스와 연관이 깊은 모델로서, 기본 생성자를 private으로 막아주고, 정적 팩토리 메소드 패턴을 적용하였고, 방문 일자와 마찬가지로 도메인 내부에서 비즈니스와 연관된 값에 대한 검증을 수행해주었습니다.

private Order(final Map<Food, Quantity> foodAndQuantity) {
    validate(foodAndQuantity);
    this.foodAndQuantity = foodAndQuantity;
}

public static Order create(final Map<Food, Quantity> foodAndQuantity) {
    return new Order(foodAndQuantity);
}

private void validate(final Map<Food, Quantity> foodAndQuantity) {
    if (isOrderOverMaxQuantity(foodAndQuantity)) {
        throw new OverMaxQuantityOrderException();
    }
    if (isContainOnlyDrink(foodAndQuantity)) {
        throw new OnlyDrinkOrderException();
    }
}

---

🚩Value Object, record 관리 기준

사용자가 입력한 값인가? ------------> Value object로서 record로 관리
else ------------> class로 관리

 

저는 위와 같은 기준선을 두고, VO에 한하여 model 패키지 내부에 vo 패키지를 두고, record로 관리하여 구분하였습니다.

 

 

Value Object를 class로 관리하는 경우 두 필드 값이 동일하면 동등, 동일한 객체로 판단하도록 equals와 hashCode 메소드를 별도로 작성하여야 합니다. Value Object로 관리하냐, 또는 단순 원시값을 포장한 class로 관리하냐, 이 기준점을 어떻게 두어야 할 지 고민이 많았는데, 저는 회원가입을 할 때 중복 아이디를 검사하거나 또는 위와 같이 회원 정보를 수정하는 경우 경우 값을 record로 관리하면, 중복 검사 별도의 검사 로직을 구현하지 않아도 필드값에 대해 equals()와 hashCode()가 자동으로 적용되기 때문에 이 Value Object를 record로 관리함으로써 코드의 복잡도를 낮출 수 있기 때문에 결론적으로 사용자가 입력한 값에 한해서 record로 관리하도록 구현하였습니다. 

 

미션과 연관된 Food record를 예로 들어 보겠습니다.

 

Order 클래스가 가지는 Map 필드에는 음식의 이름에 대한 필드값을 포장한 Food record와 수량에 대한 필드값을 포장한 Quantity가 담깁니다. 하지만 주문에는 중복된 Food의 name을 가질 수 없다는 요구사항이 있습니다. 

 

eg) 해산물파스타-1, 해산물파스타-2 ▶︎ should throw RuntimeException

public class Food {
    
    private final String name;
    
    public Food(String name) {
        validate(name);
        this.name = name;
    }

    private void validate(final String name) {
        if (!isContainInMenu(name)) {
            throw new OrderNotInMenuException();
        }
    }

    private boolean isContainInMenu(final String name) {
        return Arrays.stream(Menu.values())
                .anyMatch(menu -> menu.getSalesMenu().containsKey(name));
    }

    public boolean isDrink() {
        return DRINK.getSalesMenu()
                .containsKey(name);
    }

    public String getName() {
        return name;
    }
}

• 만약 Food record를 위와 같이 단순하게 "음식의 이름"을 원시값을 포장한 class로 관리하는 경우, equals와 hashCode메소드를 별도로 구현하지 않으면 중복된 이름에 대해 검사하는 아래의 코드가 의도대로 동작하지 않습니다.

private static Map<Food, Quantity> splitAndMapping(final List<String> menuItems) {
    return menuItems.stream()
            .map(item -> item.split(QUANTITY_DELIMITER))
            .collect(Collectors.toMap(
                    foodAndQuantity -> getFood(Arrays.asList(foodAndQuantity)),
                    foodAndQuantity -> getQuantity(Arrays.asList(foodAndQuantity)),
                    (existing, replacement) -> {
                        throw new AlreadyExistsInOrderException();
                    }
            ));
}

• 값이 동일한 경우에도 동일, 동등한 객체로 판단하지 않기 때문에 toMap의 mergeFunction에서 예외가 정상적으로 발생하지 않습니다.

public record Food(String name) {

    public Food {
        validate(name);
    }

    private void validate(final String name) {
        if (!isContainInMenu(name)) {
            throw new OrderNotInMenuException();
        }
    }

    private boolean isContainInMenu(final String name) {
        return Arrays.stream(Menu.values())
                .anyMatch(menu -> menu.getSalesMenu().containsKey(name));
    }

    public boolean isDrink() {
        return DRINK.getSalesMenu()
                .containsKey(name);
    }
}

• record는 원시값을 포장할 뿐만 아니라 레코드의 동일한 필드값에 대한 동등성, 동일성까지 보장해주기 때문에 사용자가 입력한 값을 record로 관리한다면, 이런 부분들을 신경쓰지 않아도 된다는 장점이 있습니다..

패키지는 model 패키지 외부에 별도의 vo 패키지를 두어 관리하자니, 값 객체 또한 비즈니스와 연관성이 있다고 판단해서 model 패키지 내부에 vo 패키지를 두었습니다.

---

🚩 enum 활용

➡️ enum 상수 

지난 미션 enum을 적용해본 경험이 이번 미션에서 상대적으로 쉽게 적용하도록 도왔던 것 같습니다.

지난 미션에서 발전한 점이 있다면 지난 미션에서는 연관성보다는 Type을 기준으로 enum으로 나누어 관리했다면, 이번에는 상수끼리 연관성이 있는 경우에 한해서만 enum으로 관리했다는 점입니다!

3주차 미션(좌)과 4주차 미션(우) enum 관리 예시

• 3주차 미션에서는 위 왼쪽 코드와 같이 연관성이 없음에도 불구하고 같은 Integer Type이라는 이유 하나만으로 LottoInfo enum으로 퉁쳐서 관리했는데 이제 돌아보니 이렇게 관리하게되면, 나중에 중구난방이 될 우려가 있었습니다. 
• 4주차에서는 위 오른쪽 코드와 같이 '할인 금액에 대한 정보'라는 연관성을 가지는 상수들을 DiscountInfo로 묶어 enum으로 관리했고, 아래 코드와 같이 선물과 배지에 대한 상수는 서로 연관된 정보를 여러 필드로 묶어 관리했습니다!

public enum GiftInfo {

    ONE_CHAMPAGNE("샴페인 1개", 120000, 25000),
    NONE_GIFT("없음", 0, 0);

    private final String giftName;
    private final Integer requiredAmount;
    private final Integer giftAmount;

public enum BadgeInfo {

    SANTA_BADGE("산타", 20000),
    TREE_BADGE("트리", 10000),
    STAR_BADGE("별", 5000),
    NONE_BADGE("없음", 0);

    private final String badgeName;
    private final Integer requiredAmount;

• 메뉴는 각 메뉴의 카테고리와 함께 각 메뉴의 이름과 가격을 Map을 통해 관리하도록 설정했습니다!

public enum Menu {

    APPETIZER(Map.of("양송이수프", 6000,
            "타파스", 5500,
            "시저샐러드", 8000)),
    MAIN(Map.of(
            "티본스테이크", 55000,
            "바비큐립", 54000,
            "해산물파스타", 35000,
            "크리스마스파스타", 25000)),
    DESSERT(Map.of(
            "초코케이크", 15000,
            "아이스크림", 5000)),
    DRINK(Map.of(
            "제로콜라", 3000,
            "레드와인", 60000,
            "샴페인", 25000));

 

그 외 연관성이 없고, 클래스에서만 사용하는 매직넘버들은 static final 상수로 관리하였습니다.

---

➡️ enumMap

public class Discount {

    private static final Integer NO_QUANTITY = 0;
    private static final Integer NO_DISCOUNT_AMOUNT = 0;
    private static final Integer PRESENT_YEAR = 2023;

    private final Map<DiscountPolicy, DiscountAmount> discountDetails;

 

사용자의 주문에 의해 생성된 할인 정보를 갖는 Discount 클래스의 필드를 아래와 같이 DiscountPolicy라는 enum을 두고 각 할인 금액의 원시값을 포장한 DiscountAmount와 함께 Map으로 관리하도록 구현하였습니다!

public enum DiscountPolicy {

    WEEKDAY_DISCOUNT("평일 할인"),
    WEEKEND_DISCOUNT("주말 할인"),
    D_DAY_DISCOUNT("크리스마스 디데이 할인"),
    GIFT_DISCOUNT("증정 이벤트"),
    SPECIAL_DISCOUNT("특별 할인");

---

🚩가장 고민했던 점 : 할인정책 분리 

할인 클래스의 각 할인 정책을 분리하여 관리해야 할 지 고민이 많았습니다. 분리를 가장 고민했던 이유는 할인 객체 생성자 메소드를 보면 코드가 상당히 길 뿐만 아니라 매개변수를 많이 가지고 있어 테스트가 어려워지고, 변경이 어려워지는 구조를 갖고 있기 때문이었습니다. 결론적으로는 분리를 선택하지 않았습니다. 그 이유는 

 

첫 번째, 확장성을 생각하지 않기로 한 목표를 고려해 코드를 보았을 때, 문제 될 것이 없다고 판단했습니다.

• 현재 요구사항으로는 할인 정책이 주말, 평일, 디데이, 스페셜데이, 증정이벤트 할인 총 5가지의 할인정책이 있습니다.
• 추가적인 할인 정책이 요구되는 시점이나, 할인 정책에 대한 수정이 빈번하게 이뤄지는 경우에 관리를 편하게 하기 위해 클래스 분리를 시도하는 것이 차라리 더 좋은 선택이라고 생각했습니다.

 

두 번째, 분리를 할 경우 불필요한 복잡성이 증가한다.

• 현재 Discount 클래스는 "할인 정보를 생성하여 필드로 가지는 기능, 자신의 필드값을 토대로 할인의 총 금액을 계산하여 메시지를 리턴하는 기능, 증정 이벤트의 할인 금액에 대한 메시지를 리턴하는 기능"을 가집니다. Discount 클래스가 생성자를 통한 기능을 제외하고는 두 가지 기능을 가지기 때문에 굳이 분리를 할 필요가 없다고 생각했습니다.
  • 만약 Discount 클래스가 이 두 가지의 기능 외에 다른 기능들까지 추가되어야 하는 시점에서는 할인 정책들을 분리함으로써 복잡성을 낮추는 것을 고려해보았겠지만, 현재로서는 두 가지 기능이 private 메소드르 가진다거나, 읽기 어려운 코드가 아니기 때문에 할인 정책들을 당장 분리해야 할 이유가 없다고 판단

public static Discount create(final Integer orderAmount, final Integer mainQuantity, final Integer dessertQuantity,
                              final VisitDay visitDay, final boolean isGiftReceived) {
    Map<DiscountPolicy, DiscountAmount> discountDetails = new HashMap<>();

    if (orderAmount < EVENT_ATTEND_MINIMUM_ORDER_AMOUNT.getAmount()) {
        return new Discount(discountDetails);
    }

    putWeekDayDiscount(dessertQuantity, visitDay, discountDetails);
    putWeekendDayDiscount(mainQuantity, visitDay, discountDetails);
    putD_DayDiscount(visitDay, discountDetails);
    putSpecialDayDiscount(visitDay, discountDetails);
    putGiftDiscount(isGiftReceived, discountDetails);

    return new Discount(discountDetails);
}

---

🚩 Review : 개선해야 할 점들

➡️  View로 검증 로직 옮기기

• 현재 Controller에서 discountDetails의 정보를 판단하고, 판단에 대응하는 출력뷰의 메소드를 실행하도록 작성되어 있는데, 이 보다는 뷰에서 정보를 판단하여 대응하는 메소드를 실행하도록 작성하는 것이 더 좋을 것 같습니다.

private void showDiscountDetails(final Map<DiscountPolicy, DiscountAmount> discountDetails) {
    outputView.printBenefitHeader();
    if (discountDetails.isEmpty()) {
        outputView.printNone();
        outputView.printLine();
        return;
    }
    discountDetails.forEach(
            (policy, amount) -> outputView.printBenefit(policy.getPolicy(), amount.getAmount()));
    outputView.printLine();
}

➡️ 중복 로직 제거 

public Integer getDessertQuantity() {
    return foodAndQuantity.entrySet()
            .stream()
            .filter(order -> DESSERT.getSalesMenu().containsKey(order.getKey().name()))
            .mapToInt(order -> order.getValue().amount())
            .sum();
}

public Integer getMainQuantity() {
    return foodAndQuantity.entrySet()
            .stream()
            .filter(order -> MAIN.getSalesMenu().containsKey(order.getKey().name()))
            .mapToInt(order -> order.getValue().amount())
            .sum();
}

• Order클래스에서 메인 메뉴 주문량과, 디저트 메뉴 주문량을 리턴하는 기능을 가지고 있는데, 코드에 중복되는 부분들이 있기 때문에 이 두 메소드를 아래와 같이 하나의 메소드로 변경한다면 더 좋은 코드가 될 것 같습니다.

public Integer getFoodQuantity(Menu menu) {
    return foodAndQuantity.entrySet()
            .stream()
            .filter(order -> menu.getSalesMenu().containsKey(order.getKey().name()))
            .mapToInt(order -> order.getValue().amount())
            .sum();
}

➡️ 네이밍 변경

public Integer getAmount() {
    return foodAndQuantity.keySet().stream()
            .mapToInt(food -> Menu.getPriceOfFood(food) * foodAndQuantity.get(food).amount())
            .sum();
}

• Order 클래스에서 총 주문 금액을 리턴하는 기능인데, getAmount라는 네이밍은 총 주문 금액을 설명하기에 부족하다고 느껴지는데, getAmount보다는 getTotalAmount나 getTotalOrderAmount와 같은 메소드명이 더 이 기능을 잘 나타내는 이름이라고 생각됩니다. 

---

🚩프리코스 총평 / 앞으로의 계획

 

한 달 동안의 프리코스는 기대 이상으로 많은 것을 배울 수 있었고, 주차가 진행됨에 따라 배운 지식이 체화되는 과정을 경험하게 되어 매우 유익한 시간이었습니다. 지난 한 달을 돌아보면 어려운 순간도 있었지만, 분명 내가 좋아하는 분야에서 모르고 있던 것들을 배우고 더 많이 알게 되는 과정 자체가 즐거웠던 덕에 이러한 동기부여로 프리코스에 더욱 몰두할 수 있었던 것 같습니다. 프리코스를 통해 얻은 지식과 체화된 개발 습관들은 앞으로의 개발 경력에서 큰 도움이 될 것 같습니다. 좋은 결과를 얻지 못한다 해도, 미션에 대해 사고하고 고민하며 해결하는 과정에서 배운 것들은 소중한 경험이었습니다.. 앞으로 약 한 달간의 시간 동안은 프리코스에서 배운 내용을 확실히 체화하기 위해 객체지향과 관련된 도서를 읽고, 미션을 다시 풀어보고 리팩토링하며 실력을 향상시킬 계획입니다. 특히, 기능 구현 속도를 향상시키기 위해 지난 기수들의 최종 코딩 테스트 문제들을 시간을 측정하여 풀어보고 연습할 예정입니다. 좋은 결과로 다시 후기를 이어서 썼으면 좋겠네요.

 

미션에 관한 제 코드는 아래 링크에서 확인하실 수 있습니다..

GitHub - Dongwoongkim/java-christmas-6-Dongwoongkim: 우아한테크코스 - 프리코스 4주차 미션