[인프런 김영한 로드맵2]스프링 핵심 원리 정리(1)

-인프런 김영한 강사님의 스프링 핵심 원리를 정리한다.

-모든 소스는 깃허브에서 관리한다.(https://github.com/coderahn/Spring-Lecture2)

---

1.객체 지향 설계와 스프링

 

1)자바 진영의 추운 겨울과 스프링의 탄생

 

스프링 탄생 배경을 간단하게 소개한다. 기존에 EJB라는 표준 기술을 사용하다가 로드 존슨에 의해 스프링이 세상에 처음 나왔다. 이후 몇몇의 개발자들과 퇴근하고 만들었다는데 대단하다는 생각밖에..

스프링 버전별 핵심특징은 정리해두는 것이 좋을 것 같다.

• 2003년 스프링 프레임워크 1.0 : XML
• 2006년 스프링 프레임워크 2.0 : XML 편의 기능 지원
• 2009년 스프링 프레임워크 3.0 : 자바 코드 설정
• 2013년 스프링 프레임워크 4.0 : 자바8
• 2014년 스프링부트 1.0
• 2017년 스프링 프레임워크 5.0, 스프링 부트2.0 : 리액티브 프로그래밍 지원(nodejs처럼 개발이 가능하도록 하는 기술. 아직 잘 모르겠다)
• 2022년 기준 스프링 프레임워크 5.3, 스프링부트 2.6까지 나온 것 같음

스프링은 EJB라는 겨울이 가고 새로운 봄이 온다는 뜻에서 스프링이라고 한다..기막힌 작명이다.

 

2)스프링이란?

 

스프링 생태계는 굉장히 넓다. 스프링 프레임워크, 스프링부트, 스프링데이터, 스프링세션, 스프링 시큐리티, 스프링 배치 등등..

 

여기서 가장 핵심적이고 흔히 언급하는 스프링은 스프링 프레임워크와 스프링 부트이다.

 

스프링 프레임워크 안에도 여러가지 핵심기술과 생태계가 녹아 있다.

• 핵심기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타
• 웹기술 : 스프링 MVC, 스프링 WebFlux
• 데이터접근기술 : 트랜잭션, JDBC, ORM, XML 지원
• 기타 등등..

스프링이라고 하면 흔히 스프링 DI 컨테이너 기술을 언급하는 것이기도 하고 스프링 프레임워크를 언급하는 것이기도 하다.

 

핵심 컨셉은 웹애플리케이션을 쉽게 만들어주거나 DB접근을 편리하게 해주는 기술이라기보다 자바 언어의 가장 큰 특징을 살려주는 프레임워크라는 점이다.

 

즉, 스프링은 자바의 객체지향언어라는 특징을 살려 좋은 객체지향 애플리케이션 개발을 도와주는 프레임워크라는 점이다.

 

기존 EJB를 사용했을 때는 EJB에 의존적이게 개발하여 객체지향의 장점을 잃어버렸지만 스프링을 이런 점을 극복하도록 도와준다.

 

3)좋은 객체 지향 프로그래밍이란?

 

객체지향의 특징 중, 다형성은 가장 중요한 특징 중 하나이다. 객체지향 프로그래밍은 프로그램을 유연하고 변경 용이하게 만들어주는데, 다형성이라는 특징 덕분에 이런 프로그래밍이 가능하다. 현실세계를 투영한다면 레고 블럭을 조립하듯이, 키보드와 마우스를 갈아 끼우듯이 변경할 수 있는 특징이 다형성이다.

 

다형성을 설명하기에 앞서서 실세계와 비교를 통해 설명하는데, 1:1매칭이 잘 안 되더라도 설명하기에 좋기 때문이다.

 

우선 세상을 역할(인터페이스)과 구현(클래스)으로 구분한다. 아래의 운전자-자동차 관계는 다형성을 실생활에 적용한 예시 중 하나이다.

 

출처 : 인프런 스프링핵심원리(김영한)

 

그림에서 운전자 역할은 프로그래밍에서 클라이언트이자, 인터페이스이다. 운전자라는 역할이 자동차 역할이라는 인터페이스에 의존한다. 이 경우, 자동차 역할을 구현한 구현체(클래스)가 바뀌어도 운전자에게 영향을 주지 않는다. 그렇기 때문에 유연하고 변경 용이한 프로그래밍이 가능한 것이다.

 

그밖에도 공연 무대(로미오와 줄리엣 역할), 키보드 및 마우스 등 표준 인터페이스, 정렬 알고리즘, 할인 정책 로직 등 실생활에 대입할 수 있는 다형성 예시들이 많이 있다.

 

역할과 구현을 분리하면 다음과 같은 장점이 있다.

• 클라이언트는 대상 역할(인터페이스)만 알면 됨
• 클라이언트는 구현 대상의 내부 구조를 몰라도 됨
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향 안 받음
• 클라이언트는 구현 대상 자체를 변경해도 영향 받지 않음

 

객체는 혼자 있을 수 없으며 협력이라는 관계 속에서 특징이 드러난다.

 

다형성 특징을 통해 인터페이스와 클래스를 설계했다면, 오버라이딩 기술을 통해 클라이언트는 해당 클래스 구현체의 메소드를 실행할 수 있다.

 

김영한님 로드맵1에서 MemberService가 MemberRepository 인터페이스에 의존하고, 이를 구현한 구현체(MemoryMemberRepository, JdbcMemberRepository)의 메소드(save())를 호출하는 예시를 떠올려보면 될 것 같다. 

 

출처 : 인프런 스프링핵심원리(김영한)

 

그렇다면 스프링과 다형성은 무슨 관계일까?

 

스프링은 다형성을 극대화해서 이용할 수 있게 도와준다. 제어의 역전(IoC), 의존관계 주입(DI) 등은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.

 

스프링을 사용하면 레고 블럭 조립하듯이 구현을 편리하게 변경할 수 있다.

 

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

 

객체지향의 5가지 원칙은 클린코드로 유명한 로버트 마틴이 정리한 원칙들이다.

 

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

• 한 클래스는 하나의 책임을 가져야 함
• 하나의 책임이라는 것은 기준이 모호 -> 변경이 있을 때 파급효과가 적으면 SRP를 따른 것으로 생각하자

(2)OCP : 개방 폐쇄 원칙(Open Closed Principle)

• 확장에는 열려 있으나 변경에는 닫혀 있어야 한다는 원칙
• 클라이언트가 인터페이스에 의존하면, 인터페이스 구현체가 변경되거나 확장되어도 클라이언트에 영향을 안 준다. 이 때 확장은 인터페이스를 통해 자유롭게 열려있되, 인터페이스를 의존하는 클라이언트는 변경에 닫혀 있어야 한다는 의미
• 로드맵1의 예제 중, MemberService는 MemberRepository를 의존하고 있는데 MemberRepository 선언과 함께 다형성을 이용해 구현체 인스턴스를 생성하고 있다. 이러면 클라이언트 코드에 변경이 일어나기 때문에 다형성은 사용하지만 OCP원칙을 지키지 못함
• 위와 같은 문제를 해결하기 위해 객체를 생성하고 연관관계를 맺어주는 외부 존재, 설정자가 필요 -> 스프링 컨테이너

(3)LSP : 리스코프 치환 원칙(Liskov substitution Principle)

• 객체는 프로그램 정확성을 깨뜨리지 않으면서 하위 타입 인스턴스로 바꿀 수 있어야 함
• 인터페이스 규약을 지켜 다형성을 활용해야 한다는 의미
• 예를 들어, 자동차 인터페이스의 엑셀 기능은 앞으로 가야 한다는 기능. 이를 구현한 구현체는 느리든 빠르든 앞으로 가야하는 기능의 원칙을 기준으로 가져야 함(뒤로 가면 LSP를 지키지 못했다는 것)

(4)ISP : 인터페이스 분리 원칙(Interface segregation Principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나 보다 더 나음
• 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
• 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
• 분리하면 서로 영향을 안 줌

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

• 추상화에 의존해야지 구체화에 의존하면 안 됨
• 클라이언트가 클래스가 아닌 인터페이스에 의존하라는 의미
• 앞에서 이야기한 '역할'에 의존하게 해야한다는 것

다형성만으로는 OCP, DIP를 지킬 수 없다. 스프링 컨테이너라는 빈팩토리가 필요하다.

 

5)객체 지향 설계와 스프링

 

스프링은 DI기술, DI 컨테이너를 통해 다형성+OCP, DIP를 지원한다. 클라이언트 코드 변경 없이 기능 확장을 유연하게 한다.

 

그리고 실무에서 모든 설계에 인터페이스 도입이 어렵기 때문에, 변경 가능성이 적으면 우선 클래스로 만든 후 추후 요구사항 변경시 리팩토링하는 것도 좋다.