[Spring] 스프링이란?

- 김영한 님의 '스프링 핵심원리 - 기본편'을 보고 정리한 글입니다 😊

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

| 스프링이란?

- 자바 기반의 언어 프레임워크

- 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크 

 

 

| 객체지향이란?

- 객체 지향의 기본 4가지 특성

    ✔ 추상화
    ✔ 캡슐화
    ✔ 상속
    ✔ 다형성
- 객체는 메시지를 주고받고 데이터를 처리할 수 있으며, 프로그램을 유용하고 변경이 용이하게 만든다!
- 유연하고, 변경에 용이하다.

 

---

| 그렇다면, 다형성이란 무엇일까?

- 세상을 역할과 구현으로 분리해보자.
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도, 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
    
- 그렇다면, 역할과 구현이 도대체 무엇을 말하는 걸까?
    ✔ 역할 = 인터페이스
    ✔ 구현 = 인터페이스를 구현한 (implements) 클래스
- 구현보다 역할이 더 중요하다!

- 클라이언트는 요청하는 사람, 서버는 응답하는 사람.
    - 수많은 객체 클라이언트와 객체 서버는 협력 관례를 가진다.
    - 클라이언트는 동시에 서버가 될 수도 있기에 또 다른 서버에게 요청을 할 수도 있는 것.

- JAVA에서의 다형성이란?
    - Overriding으로 수행. 오버라이딩이 된 메서드가 실행되는 것.
    - 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경 가능.
    - 당연히 클래스의 상속 관계에서도 된다. (인터페이스를 사용하는 게 다중 상속도 되고 조금 더 낫겠지만)

 

---

- 결과적으로 다형성이란
    - 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 가능
    - “협력”이라는 관점에서 객체 사이의 관계를 이해하기.
    - 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경하도록!
    - 단, 인터페이스가 변경되면 구현에도 다 영향을 끼치기 때문에, 초기에 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.
    
- 스프링에서 객체 지향은?
    - 스프링은 다형성을 극대화해서 이용할 수 있도록 도와주는 역할
    - IoC, DI는 “다형성”을 활용하여 역할과 구현을 편리하게 다루도록한 것.

 

---

 

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

✔ SRP (단일 책임 원칙)
하나의 클래스는 하나의 책임만 가져야 한다.
변경이 있을 때 파급 효과가 적게 설계하기.

 

✔ OCP (개방-폐쇄 원칙)
확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.
다형성을 통해, 인터페이스를 구현하여 새로운 클래스를 만들고, 새로운 기능을 구현하기.

MemberRepository m = new MemoryMemberRepository();
MemberRepository m = new JdbcMemberRepository()

그러나, 위와 같이 단순히 다형성을 활용하면 구현 객체를 변경할 때 클라이언트 코드를 변경해야 한다. 이러면 OCP가 깨지게 된다.
객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 생성자가 필요하다!
그리고, 이 역할을 Spring이 해주는 것.

✔ LSP (리스코프 치환 원칙)
프로그램의 객체는 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
인터페이스의 규약을 지킨 상태로 구체 클래스를 생성해야 한다.

 

✔ ISP (인터페이스 분리 원칙)
인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
클라이언트를 여러 개로 분리하고, 명확하도록.

 

✔ DIP (의존관계 역전 원칙)
프로그래머는 구현 클래스(구체화)에 의존하지 않고, 인터페이스(추상화)에 의존해야 한다.
즉, 역할에 의존해야 하며, 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있게 된다.

MemberRepository m = new MemoryMemberRepository();

현재 이 코드는 memberRepository에 할당하면서 인터페이스뿐만 아니라 구현체인 MemoryMemberRepository까지 의존하게 된다.

 

---

| 객체지향 설계와 스프링

- 다형성만으로는 구현 객체를 변경하면 클라이언트까지 변경된다.
    - OCP, DIP를 위반하게 된다.

- 이를 위해, 스프링에서는 다형성 + OCP, DIP까지 가능하도록 지원한다!
    - DI : 의존관계, 의존성 주입
    - DI Container의 제공
- 클라이언트의 코드를 변경하지 않고 기능을 확장할 수 있도록.

 

✔ 단, 역할과 구현을 구분하는 건 좋지만…
    - 실무에서는 인터페이스를 도입하면 ‘추상화’ 비용이 들어간다.
    - 코드를 파고들어가야 유지보수가 가능해진다든지… 그런 것.
    - 그렇기 때문에, 기능을 확장할 가능성이 없다면 구체 클래스를 사용하고, 필요할 때 리팩터링으로 인터페이스를 도입해도 좋다.