"왜 다형성만으로는 부족할까? SOLID 원칙과 스프링 DI의 본질"

1. 객체 지향 프로그래밍 (OOP)

객체 지향 프로그래밍은 프로그램을 단순히 명령어의 나열로 보는 것이 아니라, 여러 개의 독립된 단위인 '객체'들의 모임으로 파악하고자 하는 것입니다.

• 본질: 각각의 객체는 메시지를 주고받으며 데이터를 처리하고 협력합니다.
• 장점: 프로그램을 유연하고 변경이 용이하게 만들어줍니다.

2. 핵심 개념: 역할과 구현의 분리 (다형성)

세상을 **역할(Interface)**과 **구현(Class)**으로 구분하면 시스템이 단순해지고 유연해집니다.

• 클라이언트의 관점:
  • 대상의 역할(인터페이스)만 알면 됩니다.
  • 내부 구조를 몰라도 되며, 내부 구조가 변경되어도 영향을 받지 않습니다.
  • 구현 대상 자체를 다른 것으로 변경해도 영향을 받지 않습니다.
• 자바 언어의 활용:
  • 역할 = 인터페이스 / 구현 = 구현 클래스, 구현 객체
  • 객체 설계 시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체를 나중에 만듭니다.
• 다형성의 본질: 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있는 것입니다.

---

3. 좋은 객체 지향 설계의 5가지 원칙 (SOLID)

① SRP: 단일 책임 원칙 (Single Responsibility)

• 정의: 한 클래스는 하나의 책임만 가져야 한다.
• 판단 기준: 변경입니다. 기능 요구사항에 변경이 있을 때, 파급 효과가 적다면 이 원칙을 잘 지킨 것입니다.

② OCP: 개방-폐쇄 원칙 (Open/Closed)

• 정의: 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 보완: 인터페이스를 통해 새로운 클래스를 만드는 것(확장)은 자유롭지만, 그 과정에서 기존 코드(클라이언트 코드)를 수정하지 않아야 합니다.

③ LSP: 리스코프 치환 원칙 (Liskov Substitution)

• 정의: 프로그램의 객체는 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 의미: 단순히 컴파일 성공을 의미하는 것이 아니라, **인터페이스가 정한 규약(의도)**을 자식 클래스가 그대로 지켜야 한다는 뜻입니다.

④ ISP: 인터페이스 분리 원칙 (Interface Segregation)

• 정의: 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• 장점: 인터페이스를 기능 단위로 명확하게 나누면, 특정 기능의 변화가 다른 기능에 영향을 주지 않아 대체 가능성이 높아집니다.

⑤ DIP: 의존관계 역전 원칙 (Dependency Inversion)

• 정의: 구현 클래스에 의존하지 말고, 인터페이스(역할)에 의존해야 한다.
• 의미: 클라이언트는 서버의 구체적인 구현이 아닌, '역할'만 바라봐야 언제든 서버를 교체할 수 있습니다.

---

4. 결론: 다형성의 한계와 스프링의 등장

• 다형성만으로는 부족한 이유: 순수 자바에서는 클라이언트 코드에서 구현 객체를 지정하기 위해 new SpecificClass()와 같은 코드를 작성하게 됩니다. 이는 결국 구현체를 바꿀 때 클라이언트 코드의 수정을 불러오므로 OCP와 DIP를 위반하게 됩니다.
• 스프링의 역할: 스프링은 **DI(Dependency Injection, 의존관계 주입)**를 통해 외부에서 객체를 생성하고 연결해줍니다. 이를 통해 클라이언트 코드를 전혀 건드리지 않고도 기능을 확장하거나 교체할 수 있게 되어, 비로소 SOLID 원칙이 완성됩니다.