1. 코드 리팩토링

📍리팩토링 전 코드

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.hasNoItems()) {
        log.info("주문 항목이 없습니다.");
        return false;
    }

    if (order.isInvalidTotalPrice()) {
        log.info("올바르지 않은 총 가격입니다.");
        return false;
    }
    
    if (order.hasNoCustomerInfo()) {
        log.info("사용자 정보가 없습니다.");
        return false;
    }
    
    return true;
}

리팩토링 한 내용

• 중첩 조건문의 depth를 줄여 가독성을 개선

• 조건별 early return으로 흐름을 단순화시킴

• 조건문의 의미를 Order 내부 메서드로 만들어 메서드명 자체로 의도를 명화하게 함

• 부정 연산자를 사용하지 않도록 hasNoCustomerInfo()의 네이밍으로 변경

   

2. SOLID에 대해 나만의 언어로 정리하기

• SRP: Single Responsibility Principle

  • 하나의 클래스는 하나의 역할만 가지고 있어야 한다.

• OCP: Open-Closed Principle

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

  • 요구사항이 추가되었을 때 기존 코드를 수정하지 않고, 기능을 확장(추가)할 수 있어야 한다.

• LSP: Liskov Substitution Principle

   

  • 상속 구조에서, 자식은 부모를 대체할 수 있어야 한다.

  • 만약 자식에서 부모에는 없는 예상치 못한 예외를 던진다면 instanceOf와 같은 불필요한 처리를 해줘야 할 수도 있다.

• ISP: Interface Segregation Principle

  • 사용하는 인터페이스에만 의존하자.

  • 인터페이스 안에 필요하지 않은 기능이 있다면 인터페이스를 쪼개야 한다.

• DIP: Dependency Inversion Principle

  • 추상화 레벨이 높은 고수준 모듈에서 구체적인 저수준을 바로 의존해서는 안 되고, 추상화 즉, 인터페이스에 의존해야 한다.

출처

Readable Code: 읽기 좋은 코드를 작성하는 사고법