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

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

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

리팩토링 처리

public boolean validateOrder(Order order) {
        if (order.isEmptyItems()) {
            log.info("주문 항목이 없습니다.");
            return false;
        }
        if (order.hasNotCustomerInfo()) { // 한 번에 읽히도록 수정
            log.info("사용자 정보가 없습니다.");
            return false;
        }
        if (order.isTotalPriceLessThanOrEqualToZero()) {
            log.info("올바르지 않은 총 가격입니다.");
            return false;
        }
        return true;
    }

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

• ingle Responsibility Principle (SRP)
  • 하나의 클래스는 하나의 책임만 가져야 한다.
  • 변경이 필요한 이유가 여러 개라면 클래스를 분리해야 한다.
• Open/Closed Principle (OCP)
  • 기존 코드를 수정하지 않고 기능을 확장할 수 있어야 한다.
  • 상속과 인터페이스를 활용하여 확장성을 높인다.
• Liskov Substitution Principle (LSP)
  • 자식 클래스는 부모 클래스를 대체할 수 있어야 한다.
  • 상속 시 부모 클래스의 기능을 깨뜨리지 않도록 설계해야 한다.
• Interface Segregation Principle (ISP)
  • 클라이언트가 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.
  • 큰 인터페이스를 여러 개의 작은 인터페이스로 나누어야 한다.
• Dependency Inversion Principle (DIP)
  • 고수준 모듈이 저수준 모듈에 의존하지 않고, 추상화에 의존해야 한다.
  • 의존성을 줄이기 위해 인터페이스나 추상 클래스를 활용한다.