[백엔드 4기] Day 4 미션 제출

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

✔ 사용자가 생성한 '주문'이 유효한지를 검증하는 메서드.
✔ Order는 주문 객체이고, 필요하다면 Order에 추가적인 메서드를 만들어도 된다. (Order 내부의 구현을 구체적으로 할 필요는 없다.)
✔ 필요하다면 메서드를 추출할 수 있다.

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;
}

To Be

public boolean validateOrder(Order order) {

    if (order.isEmpty()) {
        log.info("주문 항목이 없습니다.");
        return false;
    }

    if (order.isWrongTotalPrice()) {
        log.info("올바르지 않은 총 가격입니다.");
        return false;
    }

    if (order.isCustomerInfoMissing()) {
        log.info("사용자 정보가 없습니다.");
        return false;
    }

    return true;
}

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

SRP

• 하나의 클래스는 단 한 가지의 변경 이유만을 가져야 한다.

  • 한 객체를 변경했을 때 다른 객체가 영향을 받으면 안됨

OCP

• 확장에는 열려 있고, 수정에는 닫혀 있어야 함.

• 새로운 기능을 추가한다 했을 때 기존에 있던 코드에 영향을 최소화 해야 함.

LSP

• 상속 관계에 있을 때 자식은 부모의 역할을 완벽하게 대신할 수 있어야 함.

• 부모에 자식 클래스를 갖다 놨을 때 오류가 발생하면 안 된다.

ISP

• 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안 된다.

  • 따라서 인터페이스는 하나의 기능만 담당하게 잘게 쪼개야 한다. 인터페이스 기능 중 사용하지 않는 게 있다면 안티패턴이다.

DIP

• 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다.

• 상위 수준의 모듈과 하위 수준의 모듈 모두 추상화된 것에 의존하면 된다.