1. 아래 코드와 설명을 보고, [섹션 3. 논리, 사고의 흐름]에서 이야기하는 내용을 중심으로 읽기 좋은 코드로 리팩토링해 봅시다.

원본

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.getItems().isEmpty()) {

log.info("주문 항목이 없습니다.");

return false;

}

if (order.getTotalPrice() <= 0) {

log.info("올바르지 않은 총 가격입니다.");

return false;

}

if (!order.hasCustomerInfo()) {

log.info("사용자 정보가 없습니다.");

return false;

}

return true;

}

2. SOLID에 대하여 자기만의 언어로 정리해 봅시다.

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

• 클래스는 하나의 책임만 가져야 한다.

• 변경이 필요한 이유가 하나뿐이어야 한다.

• 기능을 분리하여 유지보수를 쉽게 만든다.

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

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

• 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있도록 설계한다.

• 다형성을 활용하여 유연하게 설계한다.

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

• 자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다.

• 상속을 사용할 때 부모 클래스의 기능을 변경하지 않도록 한다.

• 다형성을 해치지 않고 일관성을 유지한다.

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

• 클라이언트가 사용하지 않는 인터페이스에 의존하지 않도록 한다.

• 하나의 큰 인터페이스보다는 여러 개의 작은 인터페이스로 분리한다.

• 불필요한 기능을 강제하지 않도록 한다.

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

• 상위 모듈이 하위 모듈에 의존해서는 안 된다.

• 추상화(인터페이스, 추상 클래스)에 의존해야 한다.

• 구체적인 클래스가 아닌 인터페이스를 활용하여 유연성을 높인다.