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

   
   [before]

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

[after]

public boolean validateOrder(Order order) {
    if (order.isItemCountEqualTo(0)) {
        log.info("주문 항목이 없습니다.");
        return false;
    }
    if (order.isTotalPriceLessThanOrEqualTo(0)) {
        log.info("올바르지 않은 총 가격입니다.");
        return false;
    }

    if (order.hasCustomerInfo()) {
        return true;
    }
    return false;
}

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

• SRP

  • 하나의 클래스는 변경의 이유가 하나여야 한다.

  • 변경의 파급력이 작아야 한다.

• OCP

  • 수정에는 닫혀 있고, 확장에는 열려 있다.

  • 새로운 기능을 추가할 때, 기존 코드의 수정이 최소화되어야 한다.

     

• LSP

  • 부모 인스턴스가 사용되는 위치에 자식 인스턴스가 와도 의도대로 동작해야 한다.

  • 자식 클래스는 선행 조건이 더 까다로우면 안 된다.

    • 기존 부모 인스턴스에서는 사전 과정에서 유효했던 것들이 자식 인스턴스에서는 유효하지 않게 될 수 있어, 자식 인스턴스가 왔을 때 의도와 다르게 동작할 수 있다.

  • 자식 클래스는 후행 조건이 느슨해선 안 된다.

    • 기존 부모 인스턴스에서는 사후 과정에서 통과되었던 범위보다 자식 인스턴스에서 더 큰 범위가 통과되면 클라이언트 입장에서 대응이 어렵다.

• ISP

  • 클래스 자신이 이용하지 않는 메서드에 의존하지 않아야 한다.

  • 인터페이스를 잘게 쪼개는 것이 좋다

• DIP

  • 상위 모듈과 하위 모듈은 추상화(인터페이스)에 의존해야 한다.

    • 상위 모듈은 하나의 기능이라고 보면, 하위 모듈은

       

  •