Spring 핵심 원리 기본편을 시작하면서, 강사님께서 강조하신 부분은 이 강의는 Spring의 기능을 설명하는 강의가 아닌, Spring이 제공하는 기능이 왜 만들어졌는지, 왜 필요한지 그리고 어떤 부분에서 활용되는지에 대해 설명하는 강의라고 하셨다.
강의를 들으면서, Spring이 제공하는 기능 뿐만 아니라 Spring이 필요한 이유에 대해 찾으면서 Spring에 대한 재미를 찾을 예정이다.
스프링이란?
스프링 생태계
구성
- 필수 : 스프링 프레임 워크, 스프링 부트
- 선택 : 스프링 데이터, 세션, 시큐리티, RestDocs, 배치, 클라우드
스프링 프레임 워크
- 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타
- 웹 기술 : 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
- 기술 통합 : 캐시, 이메일, 원격접근, 스케줄링
- 테스트 : 스프링 기반 테스트 지원
- 언어 : 코틀린, 그루비
스프링 부트
스프링을 편리하게 사용할 수 있도록 스프링 프레임워크를 사용하여서 지원
- 이전에는 스프링을 빌드하고, 톰캣을 설치해야 했는데 스프링 부트가 자체적으로 설정해준다.
- starter가 관련된 라이브러리를 다 떙겨와 손쉬운 빌드를 할 수 있다.
- 버전이 맞는지 spring boot가 테스트한다.
- 모니터링 기능을 제공한다.
- 대부분 관례에 의한 간결한 설정을 하며, 몇부분만 커스텀한다.
스프링은 문맥에 따라 다르게 사용된다.
- 스프링 DI 컨테이너 기술 : 주로 소스코드를 볼 때 사용된다.
- 스프링 프레임 워크
- 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스트링 생태계
스프링 핵심 개념
스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크이다.
객체지향의 특징 " 다형성 "
역할과 구현을 분리한다.
- 클라이언트는 대상의 역할(인터페이스)만 알면된다.
- 클라이언트는 구현 대상의 내부 구조 를 몰라도 되며, 변경 되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
- 역할 = 인터페이스
구현 = 인터페이스를 구현한 클래스 즉, 구현 객체 - 객체 설계시 인터페이스를 먼저부여하고, 구현 객체를 만들어야 한다. -> 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.
다형성의 본질
- 인터페이스를 구현한 객체 인스턴스를 실행시점에 유연하게 변경할 수 있다.
= 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있어야 한다.
좋은 객체 지향 설계의 5가지 원칙 SOLID
SRP(Single Responsibility Principle)
단일 책임 원칙 : 한 클래스는 하나의 책임만 가져야 한다.
중요한 기준은 변경으로, 변경이 있을 때 파급 효과가 적으면, 원칙을 잘 따른 것이다.
OCP(Open/Closed Principle)
개방-폐쇄 원칙 : 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
public class MemberService{
//private MemberRepository memberRepository = new MemoryMemberRepository();
private MemberRepository memberRepository = new JdbcMemberRepository();
}구현 객체를 변경하려면, 클라이언트 코드를 변경해야 한다. 즉, 다형성을 사용했지만 OCP 원칙을 지킬 수 없다.
-> 객체를 생성하고, 연관 관계를 맺어주는 별도의 조립, 설정자가 필요하다.
-> 이를 스프링 컨테이너가 해준다.
LSP(Liskob Substitution Principle)
리스코프 치환 원칙 : 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다. 인터페이스를 구현한 구현체를 믿고 사용하기 위함이다.
ISP(Interface Segregation Principle)
인터페이스 분리 법칙 : 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다.
인터페이스가 명확해지고, 대체 가능성이 높아진다.
DIP(Dependency Inversion Principle)
의존 관계 역전 원칙 : 추상화에 의존해야 하지, 구체화에 의존하면 안된다.
예시에 대입하면, MemberService가 MemberRepository 인터페이스에만 의존해야 한다. 그런데, MemberService 클라이언트가 구현 클래스를 직접 선택한다.
MemberRepository m = new MemoryMemberRepository();이는 DIP에 위반한다.
스프링을 통해서 해결
객체 지향의 설계는 다향성이었다. 하지만, 다형성만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경되었으며, OCP/DIP 를 지킬 수 없음을 알 수 있었다.
이는 스프링 프레임워크에서 제공하는 DI(Dependency Injection)으로 해결할 수 있다.
인터페이스를 도입하면, 추상화라는 비용이 발생하는데 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이라고 제시해주셨다.
다음 글은 인프런 김영한 강사님의 스프링 강의 복습용입니다 :)
