[미션]

1. 아래 코드와 설명을 보고, [섹션 3. 논리, 사고의 흐름]에서 이야기하는 내용을 중심으로 읽기 좋은 코드로 리팩토링해 봅시다.

#TO-BE

public boolean validate(Order order) {
    if (Objects.isNull(order)){
        return false;
    } 

    if (order.isItemsEmpty()) {
        log.info("주문 항목이 없습니다.");
        return false;
    } 
 
    if (order.notValidateTotalPrice()) {
        log.info("올바르지 않은 총 가격입니다.");
        return false;
    }
 
    if (order.notHasCustomerInfo()) {
        log.info("사용자 정보가 없습니다.");
        return false;
    } 
 
    return true;
}

• 메서드 시그니처

  • 메서드명 변경 (validateOrder -> validate)

    • 파라미터 타입이 있어서 Order 삭제

       

• 구현부

  • 파라미터 검증 추가

    • order이 null인 경우에도 유효하지 않다고 응답

    • 추상화 레벨에 맞춰 order == null이 아닌 Objects.isNull(order) 적용

  • Early Return 적용

    • 실제 검증항목은 아이템 개수, 아이템 가격합계, 고객 정보 유무 3가지이고, 각각 독립적이므로 불필요한 else, else if 구문 삭제

  • 부정연산자(!) 대신 메서드명에 명시

• 반환타입

  • 수정 없음

#AS-IS

public boolean validateOrder(Order order) {
    if (order.getItems().size() == 0) {
        log.info("주문 항목이 없습니다.");
        return false;
    } else {
        if (order.getTotalPrice() > 0) {
            if (!order.hasCustomerInfo()) {
                log.info("사용자 정보가 없습니다.");
                return false;
            } else {
                return true;
            }
        } else if (!(order.getTotalPrice() > 0)) {
            log.info("올바르지 않은 총 가격입니다.");
            return false;
        }
    }
    return true;
}

2. SOLID에 대하여 자기만의 언어로 정리해 봅시다.

• SRP

  • 공통적인 것들로 묶어주기

    • 같은 기능 : 메서드

    • 같은 도메인 : 클래스

• OCP

  • 동적으로 활용할 수 있게 설계

• LSP

  • 부모의 기능을 자식들이 공통으로 쓸 수 없다면 분리하기

• ISP

  • 인터페이스는 최소 단위별로 생성

• DIP

  • 추상에 의존