객체 지향 설계와 스프링 / SOLID 원칙

다형성의 본질

• 인터페이스를 구현한 객체 인스턴스를 유연하게 변경
• 클라이언트를 변경하지 않고, 서버 구현 기능을 유연하게 변경할 수 있다.

 

역할(인터페이스) / 구현(클래스)를 분리

스프링에서는 다형성이 정말 중요하다!

다형성의 장점을 극대화시키는 게 스프링!

 

SOLID 원칙

 

SRP 단일 책임 원칙

• 한 클래스는 하나의 책임만을 가져야한다.
• 클래스를 변경하였을 때의 파급 효과가 최대한 작도록 설계해야한다.

 

OCP 개방-폐쇄 원칙

• 확장에는 열려있고, 변경에는 닫혀있어야한다.
• 인터페이스 구현체를 만들어 사용 → 확장
• 서비스나 리포지토리 코드 변경은 자제

 

LSP 리스코프 치환 원칙

• 하위 클래스는 인터페이스 규약을 지켜야한다.
• 다형성을 지원하기 위한 규칙

 

ISP 인터페이스 분리 원칙

• 특정 역할 인터페이스 여러개가 범용 인터페이스 하나보다 낫다.
• 인터페이스가 명확해지고, 대체 효율성이 높아진다.

 

DIP 의존관계 역전 원칙

• 추상화에 의존해야지, 구체화에 의존하면 안된다.
• 쉽게 말해 인터페이스에 의존하라는 뜻이다.
• 인터페이스에 의존해야 구현체를 유연하게 변경할 수 있다!

 

❗ 하지만 다형성만으로는 DIP와 OCP를 지킬 수 없다.
→ 스프링이 DI 컨테이너를 제공함으로써 해결

 

 

정리

• 모든 설계에 역할과 구현을 분리하자
• 배역만 만들어두고, 배우는 언제든지 교체할 수 있는 것이 좋은 객체 지향 설계이다.
• 이상적으로는 모든 설계에 인터페이스를 활용하는 것이 좋지만, 추상화가
  항상 좋은 것은 아니다.
• 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 리팩토링하는 것도
  괜찮은 방법이다.

---

본 글은 인프런 - 스프링 핵심원리 기본편을 수강하고 정리한 글입니다.
https://inf.run/kCYMv