[인프런 워밍업 클럽 3기] BE 클린코드 - 미션 4

1. 리팩토링  해보기

public class Misson {
    public static final String MESSAGE_DOSE_NOT_EXIST_ORDER_ITEM = "주문 항목이 없습니다.";
    public static final String MESSAGE_DOSE_NOT_EXIST_USER_INFO = "사용자 정보가 없습니다.";
    public static final String MESSAGE_TOTAL_PRICE_IS_ZERO = "올바르지 않은 총 가격입니다.";

    static class Order{
        private static final List<Item> items = new ArrayList<>();
        private static String custInfo;

        public int getTotalPrice(){
            int totalPrice = 0;

            for(Item i : items){
                totalPrice += i.price;
            }

            return totalPrice;
        }

        public boolean isTotalPriceNegative(){
            return getTotalPrice() < 0;
        }

        public boolean hasNotCustomerInfo(){
            return custInfo.isEmpty();
        }

        public boolean itemIsEmpty(){
            return items.isEmpty();
        }
    }


    public boolean validateOrder(Order order) {
        if (order.itemIsEmpty()){
            log.info(MESSAGE_DOSE_NOT_EXIST_ORDER_ITEM);
            return false;
        }

        if (order.hasNotCustomerInfo()) {
            log.info(MESSAGE_DOSE_NOT_EXIST_USER_INFO);
            return false;
        }

        if (order.isTotalPriceNegative()) {
            log.info(MESSAGE_TOTAL_PRICE_IS_ZERO);
            return false;
        }

        return true;
    }
}

 

 

2. 좋은 객체 지향 설계의 5가지 원칙 SOLID

S	Single Responsibility Principle 단일 책임의 원칙	"한 클래스는 오직 하나의 책임만 가져야 한다" 클래스 하나가 애플리케이션 전반에 걸쳐 여러 일을 동시에 하면, 그 클래스를 수정 할 때마다 영향력이 커지게 된다. 이런 수정 리스크를 줄이기 위해 하나의 클래스는 하나의 역할만 작동하도록 설계 하는 것이 목표
O	Open/Closed Principle 개방 - 폐쇄의 원칙	"확장에는 열려있고 수정에는 닫혀있어야 한다." 새로운 기능을 추가하거나 요구사항이 바뀌어도 기존 코드는 최소한으로 수정되게 설계하자. 확장 기능이 필요할 때 굳이 오래된 로직을 해치지 않고, 다형성을 활용해 쉽게 덧붙일 수 있게 설계 하는 것이 목표
L	Liskov Substitution Principle 리스코프 치환 원칙	"부모 타입의 자리에 어떤 자식 타입을 넣어도 프로그램은 제대로 동작해야 한다." 부모 클래스를 대체해 다른 자식 클래스를 넣는다고 해도, 프로그램은 정상 작동 해야한다.
I	Interface Segregation Principle 인터페이스 분리 원칙	"범용 인터페이스에 의존하지 않도록 해야 한다.." 여러 개의 인터페이스로 쪼개어 설계하지 않고, 하나의 범용 인터페이스로 설계하게 되면, 수정도 어렵고 테스트도 복잡해진다.
D	Dependency Inversion Principle 의존관계 역전 원칙	"구체에 의존하지 않고, 추상에 의존해야 한다." 의존관계를 보다 유연하게 설계하기 위해 구현체에 의존하지 않고, 상위 추상 타입에 의존하면,  이렇게 되면, 변경과 확장이 용이해진다.