[인프런 워밍업 클럽 스터디] Day 4 미션

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

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

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

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

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

SOLID

객체지향 설계를 더 이해하기 쉽고 유연한 형태로, 유지 보수를 쉽게 만드는 데 도움을 주는 원칙

SRP: Single Responsibility Principal 단일 책임 원칙

하나의 클래스가 하나의 책임만 갖도록 설계함
객체의 공개 메서드, 필드, 상수 등이 객체의 단일 책임에 의해서만 변경되어야 한다.
- 상수: 동일한 퍼블릭 상수를 두 가지 객체가 사용하는 경우를 고려한다.
관심사의 분리와도 일맥상통
높은 응집도(클래스, 모듈 등이 긴밀하게 연결되어 있는 정도), 낮은 결합도(협력 관계의 2개 이상 객체에서, 한 객체가 변경될 때 다른 객체가 영향 받는 정도/ 의존성의 최소화라고도 함)

*책임의 경계선을 인식하기 위해서는 계속해서 질문을 던져 보는 경험적 측면이 필요.

OCP: Open-Closed Principle 개방-폐쇄 원칙

새로운 요구 사항의 추가와 같은 변동 사항 발생 시, 기존 코드 변경 없이 시스템의 기능을 확장한다.
추상화와 다형성을 통해 지킬 수 있다.

*난이도 조절 기능이 추가된다면> (1) 숫자 변경되었을 때 그 숫자에 맞춰 게임이 정상 진행되도록 한다 (2) 난이도 조절에 대한 요구사항에 대응한다의 순서로 기능을 추가해 나간다.

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

상속 구조에서 부모 클래스 인스턴스를 자식 클래스 인스턴스로 치환할 수 있어야 한다.
- 일반적으로
  부모 클래스보다 자식 클래스의 기능이 더 많다. 이때 부모 클래스가 기능하는 것을 자식 클래스가 해도 동일하게 동작해야 한다는 것.
LSP를 위반하면 상속 클래스 사용 시 예외가 발생하거나, 불필요한 타입 체크가 필요할 수 있다.

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

클라이언트는 자신이 사용하지 않는 인터페이스에 의존해서는 안된다. 즉 인터페이스를 기능 단위로 잘게 나눠야 한다.
ISP를 위반하면 결합도가 높아지고, 특정 기능 변경이 여러 클래스에 영향을 미칠 수 있다.

DIP: Dependency Inversion Principle 의존성 역전 원칙

상위 수준 모듈이 하위 수준 모듈에 직접 의존하지 않고, 두 개 모두 추상화에 의존해야 한다.
- 상위 수준 모듈: 추상화 레벨이 높은 쪽
- 하위 수준 모듈: 구체에 가까운 쪽

*의존성: 하나의 모듈이 다른 하나 모듈을 알고 있거나 직접 사용하는 모든 것들

의존성의 순방향: 고수준 모듈이 저수준 모듈을 참조하는 것
의존성의 역방향: (고수준 모듈) 기능을 추상화해서 추상화된 스펙을 만족하는 것을 이용해 요구사항을 해결할 수 있는 것. (저수준 모듈) 인터페이스를 구현한 구현체가 얼마든지 바뀔 수 있는 것.
즉, 추상화를 가운데 두고 의존하도록 하는 것

*DIP, DI, IoC

DIP(Dependency Inversion Principle): 고수준 모듈과 저수준 모듈은 직접적 의존이 아닌 추상화에 의존해야 한다.
DI(Dependency Injection): 필요한 의존성을 외부에서 주입받는다. "3"의 숫자를 기억할 것. 객체 a, b가 있는 상황에서 a가 b를 필요로 할 때 직접 생성자를 통해 주입 받는 것이 아닌, 제3자가 둘 사이의 의존성을 맺어준다. 스프링에서는 스프링 컨텍스트(**IoC 컨테이너)가 한다.
IoC(Inversion of Control): 프로그램 제어 주도권이 개발자가 아닌 프레임워크에 있다.

**IoC 컨테이너: 객체의 생명주기를 관리하고 의존성 주입까지 해 준다.