코드 리팩토링

public boolean validateOrder(Order order) {
    try {
	checkOrderContainsItems(order);
	checkOrderHaveValidPrice(order);
	checkOrderContainCustomerInfo(order);
	    
	return true;
    } catch(OrderException e) {
	log.error(e.getMessage());
			
	return false;
    }
}

private void checkOrderContainsItems(Order order) {
    if (order.containsNoItems()) {
        throw new OrderException("주문 항목이 없습니다.");
    } 
}

private void checkOrderContainCustomerInfo(Order order) {
    if (order.doesNotContainCustomerInfo()) {
        throw new OrderException("사용자 정보가 없습니다.");
    } 
}

private void checkOrderHaveValidPrice(Order order) {
    if (order.priceIsInvalid()) {
        throw new OrderException("올바르지 않은 총 가격입니다.");
    }
}

SOLID

단일책임 원칙

• 객체는 하나의 책임만 담당해야 하며, 이를 달성하는 데만 집중해야 한다.

• 여러 책임이 하나의 객체에 있을 경우 유지보수 시 책임간의 충돌이 일어날 수 있다.

• 책임간의 충돌은 신뢰할 수 없는 기능, 더 나아가 불완전한 프로그램이 될 수 있다.

• 즉 책임이 하나라는 것은 객체를 변경해야 하는 이유는 단 하나여야 한다는 것이다.

개방/폐쇄 원칙

• 확장에는 열려있고, 변경에는 닫혀있다는 것은 새로운 요구사항이 기존 코드에 대한 변경은 최소화 하고, 새로운 구현으로 확장해나간다는 것이다.

리스코프 치환 원칙

• 기본 객체의 기능을 파생 객체가 대체할 수 있어야 한다.

• 이를 달성하기 위해서는 해당 객체의 의도를 파악하여야 한다.

• 이러한 의도를 가장 명확하게 파악하고, 전달하는 방법은 테스트 코드

인스턴스 분리 원칙

• 클라이언트가 자신이 사용하지 않는 기능에 의존하지 말아야 한다.

• 즉 자신이 사용하지 않는 기능을 구현해야 한다면 해당 인터페이스는 이 원칙을 어긴 것이다.

• 이러한 원칙은 코드의 응집도를 높일 수 있으며, 코드의 재사용성도 높아진다.

의존성 역전 원칙

• 상위 모듈은 하위 모듈에 의존해서는 안되며, 상위 모듈과 하위 모듈은 모두 추상화에 의존해야 한다.

• 상위 모듈은 추상화에 의존해야 하며, 하위 모듈은 추상화를 구현해야 한다.

• 이러한 원칙을 통해 응집도를 높이고, 변경의 전파를 최소화할 수 있다.

결과적으로 SOLID 원칙을 지킨다는 것은 신뢰할 수 있는 프로그래밍을 위한 도구를 사용한다는 것으로 보인다.

이를 통해 협업에서 신뢰할 수 있는 분업이 가능해지고, 결과적으로 안정적인 프로그램을 구축할 수 있다고 생각된다.

참고: 자바/스프링 개발자를 위한 실용주의 프로그래밍, 김우근 - 위키북스