스프링을 쓰는 이유/핵심 = 객체 지향
객체 지향의 특징
: 추상화 / 캡슐화 / 상속 / 다형성
- 프로그램을 유연하고 변경이 용이하게 만들 수 있다!!(다형성)
다형성⭐
(자동차 예시)
- 자동차 인터페이스만 알면 구현체(차의 기종)이 달라져도 자동차를 운행할 수 있다
- 운전자(클라이언트)는 자동차의 내부 구조를 몰라도 자동차를 운행할 수 있다
=> 클라이언트에 영향을 주지 않고 새 기능을 제공할 수 있다
(공연 무대 예시)
- 로미오 역할을 누가 하든 대본만 알면 연기할 수 있다
- 서버와 클라이언트 관계에서도 다형성 적용 가능
- 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다!
- 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다
SOLID(좋은 객체 지향 설계의 5가지 원칙)
SRP(single responsibility principle)
OCP(open/closed principle)
- 클라이언트 코드인 MemberService를 변경해야 한다(OCP 원칙 지킬 수 없다)
=> 스프링 컨테이너
LSP(liskov substitution principle)
- 기능적인 규약을 지키는 것을 보장해 주어야 한다
ISP(interface segregation principle)
- 인터페이스를 단일 기능으로 분리
DIP(dependency inversion principle)
- 역할에 의존해야지, 구현체에 의존해서는 안 된다
- MemberService 클라이언트가 구현 클래스를 직접 선택(DIP 위반)
=> 스프링
(요약)
- 객체 지향의 핵심은 다형성이다
- 모든 설계에 역할과 구현을 분리하자
- 구현체를 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계이다
- 이상적으로는 모든 설계에 인터페이스를 부여하자
(하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다)
(=> 기능을 확장할 가능성이 없으면,
구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이다)
- 다형성만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다
(구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다) - 다형성만으로는 OCP, DIP를 지킬 수 없다
- 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원
=> DI(Dependency Injection) : 의존관계, 의존성 주입
=> DI 컨테이너 제공
==> 클라이언트의 코드 변경 없이 기능 확장
🏛️❄💻😻🏠