객체 지향 설계의 5가지 원칙(SOLID)

1. SRP 단일책임의 원칙

기능을 변경했을 때 연계되는 변경이 많다면 단일 책임 원칙을 지키지 못한 것

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

2. OCP 개방폐쇄의 원칙

소프트웨어 요소는 확장에는 열려있고 변경에는 닫혀 있어야 한다. 즉, 다형성 특징을 활용해서 확장은 가능한 반면 변경은 없는 것을 말한다. 단, 스프링의 DI(컨테이너)를 함께 활용해야 가능하다.

3. LSP 리스코프 치환의 원칙

자동차의 경우 엑셀을 밟으면 앞으로 가는 기능을 구현해야 한다. 하위 클래스도 엑셀이라는 인터페이스를 상속받았을 때 앞으로 가는 기능을 구현해야 한다. 뒤로 가게 구현한다면 LSP 위반

-> 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

4. ISP 인터페이스 분리 원칙

자동차를 사용하는 경우 운전과 정비가 있는데 이 두 역할, 즉 인터페이스를 분리하자. 특정 클라이언트를 위해 특화된 인터페이스를 제공하자. 

5. DIP 의존관계 역전의 원칙 

구체적인 구현이 아닌 역할(추상화, 인터페이스)에 의존해야 한다.

-> 프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다.

 

[OCP와 DIP 원칙을 지킨 사례]

자바 코드로만 작성

1. 주문 서비스 인터페이스를 구현한 주문 서비스 클래스이다.
2. 주문를 생성하는 매서드에서 회원 저장소와 할인 정책 클래스를 사용해야 한다.
3. 초기에는 주석 처리된 부분과 같이 할인 정책의 인터페이스와 구현체를 모두 작성하고 의존하고 있다.
4. 이는 DIP 원칙을 위반한 사례이며 고정 할인 대신 비율 할인으로 변경하기 위해서는 직접 구현체를 이 서비스 단에서 끼워넣어야 하기 때문에 OCP 원칙 또한 위반했다.
5. 이를 해결하기 위해서는회원 저장소와 할인 정책을 먼저 선언해주고 생성자를 통해 각각을 인터페이스로 의존성 주입해주면 된다.
6. 그리고 실제로 인터페이스에 구현체를 정해주는 (구성) 곳은 아래 코드와 같아 AppConfig 클래스이다.
7. 아래 처럼 특정 클래스에서 필요한 구체를 설정해주는 코드이며
8. 변경이 필요하다면 이 클래스에서 레고 블럭 갈아끼우듯 바꿔주면 된다.
9. 그리고 아래에서 볼 수 있듯이 이 코드 내부에서도 역할과 구현을 분리하여 작성했음을 알 수 있다.
10. 실제로 구현체가 변경되어야 하더라도 사용 코드들은 인터페이스를 참조하고 있기 때문에 이 곳에서만 처리를 해주면 된다.