1.

    public boolean validateOrder(Order order) {
        if (order.hasNoItems()) {
            log.info("주문 항목이 없습니다.");
            return false;
        }

        if (order.hasInvalidPrice()) {
            log.info("올바르지 않은 총 가격입니다.");
            return false;
        }

        if (order.hasNoCustomerInfo()) {
            log.info("사용자 정보가 없습니다.");
            return false;
        }

        return true;
    }

- SRP 단일책임원칙

하나의 클래스는 하나의 책임만을 가지고 있어야 한다. 그래야 하나의 변경점을 가지고 코드를 수정해야 할 때 하나의 클래스만을 수정할 수 있다. → 높은 응집도와 낮은 결합도를 의미한다.

결합도가 낮다는 것은 다시 말하면 서로 다른 클래스간 연관성이 낮고 하나의 클래스가 수정될 때 다른 클래스가 수정되지 않는 것을 의미한다.

- OCP Open-Closed Principle

추상화와 다형성을 활용해 코드의 수정 없이(Closed) 언제든 기능추가를 쉽게 할 수 있어야 한다(Open). 코드를 작성할 때 어떤 상수값이나 어떤 구체클래스에 의존해서 작성하면 상수값이 바뀌거나 구체클래스가 바뀌게 되면 이걸 사용하는 코드가 다 변경되어야 한다. 사용하는 값이나 클래스가 바뀌더라도 유연하게 사용할 수 있도록 코드를 작성해야 된다.

- LSP

부모 클래스로 선언된 변수가 자식클래스의 인스턴스든, 부모클래스의 인스턴스든 같은 역할을 하고 같은 행동을 해야 한다. 다르게 말하면 어떤 클래스를 상속받았으면 그 클래스의 특징을 그대로 받아야 하고 말그대로 원래의 기능에다가 확장할 뿐이다. 원래의 기능을 변경하면 안된다.

구체적인 상황에서 보면 부모클래스의 인스턴스를 자식클래스의 인스턴스가 치환되더라도 부모클래스 인스턴스의 행동과 다르지 않아야 한다.

- ISP

인터페이스의 기능 <= 인터페이스를 구현하는 클래스의 기능

인터페이스를 구현하는 클래스의 기능보다 인터페이스의 기능이 더 많아서 구현하는 클래스에서 다 구현하지 못한다면 인터페이스를 쪼개야 한다. 약간 인터페이스의 SRP(단일책임원칙)? 같은 느낌. 너무 많은 기능(책임)이 있으면 쪼개라! 구현하는 클래스 입장에서는 구현해야되는 인터페이스의 수의 변화만 있을뿐이다.

- DIP

추상화레벨이 높은 모듈,클래스 등에서 추상화 레벨이 낮은 모듈,클래스를 의존해야 할 때 의존 대상을 추상화해서 의존해야 한다. (구체클레스보다는 이를 추상화한 인터페이스를 의존). 추상화 레벨이 낮을 수록 변경 가능성이 높기 때문에 추상화 하지 않은 저수준 모듈을 직접 의존하게 된다면 저수준 모듈에 변경이 있을 때 고수준 모듈에도 변경이 필요하게 된다.