워밍업 클럽 2기 BE 클린코드&테스트코드 DAY 4 미션

보기 좋은 코드 작성법

• 예외가 발생할 가능성 낮추기
• 어떤 값의 검증이 필요한 부분은 주로 외부 세계와의 접점
• e.g) 사용자 입력, 외부 사용자 요청
• 의도한 예외와 예상하지 못한 예외를 구분하기

Null을 대하는 자세

• 항상 NPE를 방지하는 방향으로 경각심을 가지기
• 메서드 설계 시 return null을 자제하기
• Optional은 꼭 필요한 상황에서 반환 타입에 사용
• 반환받았다면 최대한 빠르게 해소하기

 

강의내용을 바탕으로 리팩토링을 해보았다. 

 

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) {
        isMoreThenOne();
        checkTotalPrice();
        isUser();

        return true;
    }

    public boolean isUser() {
        if (order.hasCustomerInfo()) {
            return true;
        }

        throw new IllegalArgumentException("사용자 정보가 없습니다.");
    }

    public boolean isMoreThenOne() {
        if (order.getItems().size() == 0) {
            throw new IllegalArgumentException("주문 항목이 없습니다.");
        }

        return true;
    }

    public boolean checkTotalPrice() {
        if (order.getTotalPrice() == 0) {
            throw new IllegalArgumentException("올바르지 않은 총 가격입니다.");
        }

        return true;
    }

 

else절을 제외하고, 부정절을 사용하지 않는 방향으로 리팩토링하려고 노력하였다.

아닌 경우는 에러를 던져 사용자가 에러 문구를 확인할 수 있도록 짜보았다!

간결하고 더 보기 좋아진 것 같다 야호!

 

2. SOLID 원칙 자신만의 언어로 정리하기

• 단일 책임 원칙 (Single Responsibility Principle)
  클래스는 하나의 책임만 가져야 하며, 그 책임을 모두 수행하는 데 집중해야 합니다. 이로 인해 클래스가 변경될 이유는 하나뿐이어야 합니다. 예를 들어, 데이터 처리와 UI 로직을 한 클래스에 담지 말고, 각각의 책임에 따라 분리하면 유연한 변경이 가능합니다.
• 개방-폐쇄 원칙 (Open-Closed Principle)
  소프트웨어 엔티티는 확장에 열려 있어야 하고, 수정에는 닫혀 있어야 합니다. 기능을 추가할 때 기존 코드를 변경하지 않고 새로운 코드로 기능을 확장할 수 있어야 합니다. 이를 위해 인터페이스와 다형성을 적극적으로 사용합니다.
• 리스코프 치환 원칙 (Liskov Substitution Principle)
  서브타입은 언제나 자신의 기반 타입으로 교체될 수 있어야 한다는 원칙입니다. 즉, 부모 클래스를 사용하는 곳에 자식 클래스를 사용해도 문제가 없어야 합니다. 이를 통해 클래스 간 일관성을 유지하고, 코드의 안정성을 확보할 수 있습니다.
• 인터페이스 분리 원칙 (Interface Segregation Principle)
  하나의 일반적인 인터페이스보다는 구체적인 작은 인터페이스들을 여러 개 만들어 사용하는 것이 좋다는 원칙입니다. 불필요한 메서드를 강요하지 않도록, 필요한 기능만 구현하도록 인터페이스를 나누어야 합니다.
• 의존성 역전 원칙 (Dependency Inversion Principle)
  고수준 모듈이 저수준 모듈에 의존하는 대신, 추상화에 의존해야 한다는 원칙입니다. 즉, 의존성을 하위 구현이 아닌 인터페이스나 추상 클래스에 두어야 유연성과 재사용성을 높일 수 있습니다.