[인프런 워밍업 클럽 스터디 4기 - 백엔드]

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

Day4 미션 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.isEmptyOrder()) {
        log.info("주문 항목이 없습니다.");
        return false;
    }
    if (order.isInvalidTotalPrice()) {
        log.info("올바르지 않은 총 가격입니다.");
        return false;
    }
    if (order.isEmptyCustomerInfo()) {
        log.info("사용자 정보가 없습니다.");
        return false;
    }
    return true;
}

리팩토링 적용 내용

1) Early Return : 불필요한 else를 제거하고, 조건이 맞지 않을 경우 즉시 return 하도록 하여 전체 흐름을 더 간결하게 만들었습니다.

2) 사고의 depth 줄이기 : 중첩된 조건문을 제거하고, 각 조건을 평평하게 분리하여 코드의 읽기 흐름이 깊어지지 않도록 개선하였습니다.

3) 부정 연산 최소화 : 부정 연산자의 사용을 줄이고, 메서드 이름에 긍정적인 의미를 담아 코드를 직관적으로 이해할 수 있도록 표현하였습니다.

4) getter 사용 자제 : getter를 직접 호출하지 않고, Order 내부에 메서드를 정의하여 객체가 스스로 판단하도록 설계하여 캡슐화 원칙을 유지하였습니다.

5) 명확한 이름 짓기 : 메서드 이름에 행위와 의미가 잘 드러나도록 하여, 조건의 의도를 한눈에 파악할 수 있도록 리팩토링하였습니다.

Day4 미션 2 :

SOLID에 대하여 자기만의 언어로 정리

SRP - 단일 책임 원칙 (Single Responsibility Principle)

• 하나의 클래스는 하나의 역할에만 집중해야 한다.

• 여러 이유로 동시에 변경되지 않도록, 변경의 책임을 하나로 제한한다.

OCP - 개방/폐쇄 원칙 (Open-Closed Principle)

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

• 새로운 기능이 생겨도 기존 코드를 고치지 않고, 유연하게 확장할 수 있도록 한다.

LSP - 리스코프 치환 원칙 (Liskov Substitution Principle)

• 자식 클래스는 부모 클래스가 사용되는 자리에서 자연스럽게 대체 가능해야 한다.

• 상속을 했다면 부모의 역할과 일관된 동작을 유지해야 한다.

ISP - 인터페이스 분리 원칙 (Interface Segregation Principle)

• 하나의 큰 인터페이스보다, 역할에 맞게 나눈 인터페이스를 제공하는 것이 좋다.

• 사용하지 않는 메서드를 억지로 구현하지 않도록 필요한 기능만 나눠서 설계한다.

DIP - 의존 역전 원칙 (Dependency Inversion Principle)

• 구체적인 구현보다 인터페이스에 의존하도록 만든다.

• 그래야 서로 유연하게 연결되고, 변경에 강한 구조를 만들 수 있다.