문제 1)
아래 코드와 설명을 보고, 섹션 3. 논리, 사고의 흐름에서 이야기하는 내용을 중심으로 읽기 좋은 코드로 리팩토링해 봅시다.
✔️ 사용자가 생성한 '주문'이 유효한지를 검증하는 메서드.
✔️ Order는 주문 객체이고, 필요하다면 Order에 추가적인 메서드를 만들어도 된다. (Order 내부의 구현을 구체적으로 할 필요는 없다.)
✔️ 필요하다면 메서드를 추출할 수 있다.
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;
}TO-BE
public boolean validateOrder(Order order) {
if (order.hasNotItems()) {
log.info("주문 항목이 없습니다.");
return false;
}
if (order.hasNotCustomerInfo()) {
log.info("사용자 정보가 없습니다.");
return false;
}
if (order.isTotalPriceLessThanZero()) {
log.info("올바르지 않은 총 가격입니다.");
return false;
}
return true;
}문제 2)
SOLID에 대하여 자기만의 언어로 정리해 봅시다.
1. SRP
클래스가 변경될 이유는 한 가지로, 클래스 설계 시, 하나의 관심사로 응집하여 구현하도록 해야 한다.
2. OCP
기존 코드의 변경 없이, 기능 추가하도록 설계가 되어야 한다. 다형성을 이용하여 클라이언트 코드의 변경 없이 구현체를 쉽게 변경이 가능하다.
3. LSP
부모 클래스에서 정의한 스펙을 자식 클래스에서도 지켜야 한다. instance of로 타입 체크하여 특정 타입에 대해서만 처리가 필요하다는 건 LSP를 위반한 사례이다.
4. ISP
SRP와 비슷하게 인터페이스 또한 한 가지 책임을 가지도록 분리해야한다.
5. DIP
클래스 참조 시, 추상화 레벨이 높은 인터페이스, 추상클래스, 상위 클래스를 참조하도록 한다. 코드에 구현체가 드러나게 되면 기능 변경시, 클라이언트 코드의 변경이 생기므로 추상화 레벨이 높은 인터페이스 등을 메소드 파라메터, 필드, 리턴타입으로 활용하도록 한다.
Junior Backend Developer