public boolean validateOrder(Order order) {
    if (hasNoItems(order)) {
        log.info("주문 항목이 없습니다.");
        return false;
    }
    if (hasInvalidTotalPrice(order)) {
        log.info("올바르지 않은 총 가격입니다.");
        return false;
    }
    if (hasNoCustomerInfo(order)) {
        log.info("사용자 정보가 없습니다.");
        return false;
    }
    return true;
}

SOLID

• 단일 책임 원칙 (Single Responsibility Principle):
  클래스는 오직 하나의 책임만 가져야 하며, 변경의 이유도 하나여야 합니다.
  이를 통해 클래스는 더 작고 관리하기 쉬운 단위로 나누어질 수 있습니다.
  여러 책임을 가진 클래스는 수정 시 영향 범위가 커지고, 유지보수성이 낮아질 수 있습니다.

• 개방-폐쇄 원칙 (Open/Closed Principle):
  소프트웨어는 기능을 확장할 수 있어야 하지만, 기존 코드를 수정하지 않아야 합니다.
  이는 주로 인터페이스나 추상화를 통해 달성되며, 코드 수정 없이 새로운 기능을 추가할 수 있게 합니다.
  이 원칙을 지키면 기존 기능이 안정적으로 유지되고, 새로운 요구사항에 대응하기 쉬워집니다.

• 리스코프 치환 원칙 (Liskov Substitution Principle):
  자식 클래스는 부모 클래스에서 기대되는 기능을 모두 수행할 수 있어야 합니다.
  자식 클래스가 부모 클래스 대신 사용되더라도 프로그램의 기능은 변하지 않아야 합니다.
  이를 지키면 클래스 간 상속 구조에서 예기치 않은 오류를 방지할 수 있습니다.

• 인터페이스 분리 원칙 (Interface Segregation Principle):
  클라이언트는 자신이 사용하지 않는 인터페이스나 메서드에 의존하지 않아야 합니다.
  큰 인터페이스를 작게 분리함으로써 클라이언트가 필요하지 않은 기능에 의존하는 것을 피할 수 있습니다.
  이렇게 하면 불필요한 코드 의존성을 줄이고 유지보수성을 높일 수 있습니다.

• 의존성 역전 원칙 (Dependency Inversion Principle):
  고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다.
  이는 구체적인 구현보다는 인터페이스나 추상 클래스를 통해 모듈 간 의존성을 줄이는 방식입니다.
  이 원칙을 따르면 시스템이 유연하고 확장 가능해지며, 변경에 더 잘 대응할 수 있습니다.