스프링의 탄생
EJB: 스프링 이전의 기술로 객체지향의 장점을 살리지 못해 사라졌다.
POJO: 순수한 자바로 돌아가자
2002년 로드존슨
스프링이란?
명확하게 정의하기 어렵다.
- 스프링 프레임워크: 자바 플랫폼을 위한 오픈소스 애플리케이션 프레임워크
- 스프링부트: 스프링을 편리하게 사용할수있게 하는 프로그램으로 최근에는 기본적으로 다 사용한다.(톰캣같은거 안깔아도되며 라이브러리들과의 버전호환을 알아서 맞춰준다)
스프링부트는 스프링을 편리하게 사용해주게 하는 서브의 느낌이라 독자적으로 쓰이기 보다는 프레임워크와 같이 쓰인다.
스프링은 왜 만들어졌나?
자바 기반의 객체지향 언어로 객체 지향을 강조하는 프레임워크이며 좋은 객체지향으로 가고자 한다. 이 핵심을 알고 스프링을 공부하면 더 재밌고 잘 공부할 수 있다.
좋은 객체지향이란?
객체들을 하나의 독립된 단위로 보며 유연하고 변경용이하다.(ex. 레고블록)
- 다형성(Polymorephism): 역할(iterface)과 구현(구현객체)을 나눈다.
즉, 서로간 영향을 주지 않으며 요청을 하는 클라이언트는 인터페이스만 알면 된다.
역할을 담당하는 인터페이스를 잘 만들면 그 안에서 여러개의 구현체를 유연하게 구현할 수 있다.
역할과 구현을 분리함으로서 내가 원할때 원하는 역할을 가지고 와서 쉽게 변경을 할 수 있다.
클라이언트는 내부구조를 몰라도 되며 내부구조가 변경되어도 영향을 받지않는다.
ex) 운전자(클라이언트)를 위해서 자동차의 역할을 나눔 -> 새로운 자동차가 나와도 운전자는 영향을 받지않는다. == 운전자가 자동차가 변한다고 해서 운전을 못하지 않는다.
ex)memberRepository의 역할을 계속해서 만들어낼수있다.
memberReposiory 인터페이스(역할)를 그 뒤 필요에 따라 다양한MemoryMemberRepository, JpaMemberRepository 등 여러개의 구현체를 만들 수 있다.
단, interface가 깨지지않는 조건 하에 -> interface를 안정적으로 잘 만들어놔야한다.
스프링은 좋은 객체 지향의 요소인 다형성을 극대화 할 수 있게 도와준다.
SOLID - 좋은 객체 지향 설계의 5가지 원칙
- SRP(단일책임원칙) : 한 클래스는 하나의 책임만을 가져야한다.
- OCP(개방-폐쇄원칙) : 확장에는 열려있으나 변경에서는 닫혀있어야 한다.
-> 다형성을 활용하자.
이건 DI, 컨테이너를 통해서 해결한다.
3.LSP(리스코프 치환 원칙) : 컴파일을 넘어 기능적인 규약도 맞춰줘야한다.(ex. 악셀이라면 무조건 앞으로 가게 만들어야한다.) - ISP(인터페이스 분리원칙) : 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다. (기능을 맞게 적당한 크기로 쪼개야 한다.)
- DIP(의존관계 역전원칙) : 추상화에 의존하되 구체화에 의존하면 안된다.
즉, 클라이언트는 역할인 인터페이스를 바라보고 있어야지 구현체에 의존하면 안된다.
(의존한다 == 알고 있다.)
객체지향의 핵심은 "다형성"이나, 이 만으로는 SOLID에 맞게 클린 코드개발이 불가하며 스프링이 제공하는 DI가 있어야 한다.
- DI(Dependency Injection): 의존관계, 의존성 주입
- 모든 설계는 역할과 구현을 분리해야한다. -> 유연하게 변경할 수 있게 만들어야한다.
- 추상화 -> 개발자가 코드를 한번 더 열어봐야한다. 구현클래스가 뭔지 한번 더 봐야한다.
- 확장가능성이 있으면 interface로 만든다. 아니면 그냥 바로 구현해도 된다.
- 참고할만한 도서
객체지향: 객체지향의 사실과 오해
스프링: 토비의 스프링
jpa: jpa 김영한
참고: <김영한, 인프런: 스프링 핵심원리 - 기본편>
