1. 읽기 좋은 코드로 리팩토링

class Order {

    private List<Item> items;
    private Customer customer;

    public Order(List<Item> items, Customer customer) {
        this.items = items;
        this.customer = customer;
    }

    public boolean isEmptyOrderItems() {
        return items.isEmpty();
    }

    public boolean isNotGetTotalPrice() {
        int sum = items.stream().mapToInt(Item::getItemPrice).sum();
        return sum == 0;
    }

    public boolean isNotCustomerInfo() {
        return customer == null;
    }
}



public boolean validateOrder(Order order) {
    if (order.isEmptyOrderItems()){
        log.info("주문 항목이 없습니다.");
        return false;
    }

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

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

   return true;
}

부정연산자 제거

• !order.hasCustomerInfo()

• !(order.getTotalPrice())

• 부정 연산자는 가독을 떨어 트리기 때문에 부정 연산자를 제거 하고 not을 붙여서 메서드명으로 변경 했습니다.

Early return

• early return을 사용하여 다음 조건절을 신경 안 쓸 수 있게 변경 했습니다.

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

SRP (단일책임 원칙)

• 하나의 클래스는 한 가지의 책임만을 가져야 한다.

• 클래스는 하나의 책임만 가지기 때문에 가독성과 유지보수성이 좋음

OCP (개방폐쇠 원칙)

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

• 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있어야 함

LSP (리스코프 치환 원칙)

• 자식 클래스는 언제든지 부모 클래스를 대체 할 수 있어야 함

• 부모 타입으로 자식 객체를 사용해도 기능이 문제가 되지 않아야 함

ISP(인터페이스 분리 원칙)

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

• 불필요한 기능에 의존하지 않도록 인터페이스를 작고 명확하게 나누어야 함

DIP(의존성 역전 원칙)

• 고수준 모듈은 저수준 모듈에 의존하지 않아야 하고 둘다 추상화에 의존해야한다.

• 고수준 모듈이 저수준 모듈에 끌려가지 않도록, 추상화를 통해 분리