본 게시글은 인프런 워밍업 클럽 워밍업 클럽 2기 BE 클린코드&테스트의 DAY4 미션의 내용을 작성하였습니다.
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;
}
개선 가능한 부분
1. if-else 의 중첩으로 인하여 코드를 확인하기 힘들다
2. order 에서 위임하여 처리가능한 부분이 존재함
3. 빠르게 응답이 가능한 형태로 변환 가능
개선한 부분
public boolean validateOrder(Order order) {
if (order.isEmpty()) {
log.info("주문 항목이 없습니다.");
return false;
}
if (order.isValidTotalPrice()) {
log.info("올바르지 않은 총 가격입니다.");
return false;
}
if (order.hasNotCustomerInfo()) {
log.info("사용자 정보가 없습니다.");
return false;
}
return true;
}
public class Order(){
private final List<String> items = new ArrayList<>();
private final int totalPrice;
private final Customer customer;
public boolean isEmpty() {
if(items.isEmpty()) {
return true;
}
return false;
}
public boolean isValidTotalPrice(){
return totalPrice != null && totalPrice > 0;
}
public boolean hasNotCustomerInfo(){
return customer == null;
}
}개선한 부분
1. if-else 의 중첩을 Early Return 을 활용하여 중첩 제거
2. order.getTotalPrice() 보다는 order 에게 TotalPrice 를 확인하는 부분을 위임
3. order.hasCustomerInfo 에서 ! 를 사용해서 부정적인 표현보다는 긍정적인 표현으로 변경
2. SOLID에 대하여 자기만의 언어로 정리해 봅시다.
- 함수형 프로그래밍도 나오고 발전하고 있는 현 상황에서는 무조건적인 진리는 아니지만 그래도 정확하게 왜 나온지 알고 이해를 해야하는 것 같다.
SRP : Single Responsibility Principle
- 하나의 객체는 각자에 맞는 책임을 가지게 설계를 해야한다.
OCP : Open-Closed Principle
추상화와 다형성을 이용!
- 객체 자체는 무엇이 들어와도 처리가능 하게
- 인터페이스를 통해 다양한 값이 들어 올 수 있도록 처리
LSP : Liskov Subsitution Principle
- 부모에서의 기능을 자식에서도 동일하게 동작을 해야한다.
- 다른 개발자가 의도한 기능이 안되면 문제가 발생하게 된다.
- 동일한 동작을 하지 않을 경우 불필요한 검증이 필요하게된다.
ISP : Interface Segregation Principle
- 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안된다. → 인터페이스를 잘게 쪼개라
- ISP를 위반하면, 불필요한 의존성으로 인해 결합도가 높아지고, 특정 기능의 변경이 여러 클래스에 영향을 미칠 수 있다.
※ 기능단위로 인터페이스를 작게 사용해라!
DIP : Dependency Inversion Principle
- 의존성 : 하나의 모듈이 다른 하나의 모듈을 생성하거나 사용하는 모든 것, 참조하는 것
- 의존성 순방향 : 고수준 모듈이 저수준 모듈을 참조
추가 TIP
DIP (Dependency Inversion Principle
- 고수준 모듈과 저수준 모듈은 추상화(인터페이스)를 통해 연결 되어야 한다.
DI (Dependency injection) - 의존성 주입
- 필요한 의존성을 외부에 주입 받겠다.
IOC (Inversion of Control)
- 제어의 순방향 -> 프로그램은 개발자가 만듬, 개발자가 제어
- 제어의 역전 -> 내가 만든 프로그램이 프레임워크내에서 내 코드가 제어되어 돌아간다.
기존에 알고 있었던 부분에 대해서는 조금 더 이해도가 높아지고 읽히기 쉽게 코드를 작성할 수 있을거 같은 느낌이 듭니다. 반복 숙달을 통해 몸에 스며들때까지 열심히 하겠습니다!!