김영한님의 스프링 핵심 원리 수업을 듣고 정리한 내용입니다.
자바 진형의 추운 겨울과 스프링의 등장
✔️ EJB(Enterprise Java Beans)는 자바 서버 모델 중 하나이다. 스프링 등장 이전 사용되고 있던 자바의 공식적인 프레임 워크이다.
하지만 단점이 너무 많았다
- 가장 큰 문제로 지적되는것이 실행 속도가 느리다는것이다. 이는 분산환경을 지원하기 위해 객체를 직렬화하는 과정 때문에 실행 속도의 저하가 발생한다.
- 복잡한 프로그래밍 모델
- 특정환경, 특정기술에 종속적인 코드
- 자동화된 테스트가 매우 어렵거나 불가능
개발자들 사이에서 순수 자바 코드로 돌아가자는 운동이 있었을 만큼 어려웠고 복잡했다.
✔️ Rod Johnson의 등장
책을 하나 내는데 거기에는 EJB를 대체할 수 있는 3만 라인 이상의 코드를 예제를 들어 서술했다. 이게 스프링 프레임워크의 시초이다.
여기에 유겔 휠러, 얀 카로프가 같이 합세해서 같이 스프링 프레임워크를 본격적으로 만듦
✔️ 하버네이트의 등장
EJB 엔티티빈 기술을 대체
EJB 매우 허술...
하버네이트 오픈소스를 다듬어서 JPA인 자바 표준을 만든다.
스프링이란?
스프링 프레임워크
- 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타.
- 웹 기술 : 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술 : 트랜젝션, JDBC, ORM지원, XML지원
- 기술 통합 : 캐시, 이메일, 원격접근, 스케줄링
- 테스트 : 스프링 기반 테스트 지원
- 언어 : 코틀린, 그루비
스프링 프레임워크는 50%이상이 설정이라는 말이 나올 정도로 설정에 긴 시간 할애 -> 이를 해결해 준 것이 스프링 부트
스프링 부트는 어쩌면 껍데기
알멩이는 스프링 프레임워크
스프링을 편리하게 사용할 수 있도록 지원, 최근 기본으로 사용
스프링은
- 자바 언어 기반의 프레임워크
- 진짜진짜 객체 지향 언어의 특징을 살려주는 프레임워크
- 좋은 객체 지향 개발 가능하게 해준다.
좋은 객체 지향 프로그래밍
객체 지향의 특징
- 추상화
- 캡슐화
- 상속
- 다형성
객체 지향 프로그래밍이란?
컴퓨터 프로그래밍 ≠ 명령어의 목록
컴퓨터 프로그래밍 = 여러 개의 독립된 단위인 객체들의 모임
이 객체들은 서로 메세지를 주고 받고, 데이터를 처리
-> 유연하고 변경에 용이
마치 조립식 스마트폰처럼
다형성
역할과 구현으로 세상을 구분
운전자는 자동차 면허증을 딸 때 아반떼, K3, 테슬라모델3 처럼
차종을 알 필요가 없다 그냥 자동차 면허를 따면 차종 상관없이 운전을 할 수 있다. 운전자는 자동차에 대한 인터페이스만 알지만 자동차 세상을 무한히 확장할 수 있다.
이는 코딩과 비교하면 클라이언트에 영향 없이 새로운 기능으로 변경이 가능하다는 것이다.
역할 : 인터페이스
구현 : 인터페이스를 구현한 클래스, 구현 객체
클라이언트(객체)---요청--->인터페이스A(역할)---->를 구현한 객체a, 클래스a
클라이언트(객체)---요청--->인터페이스A(역할)---->를 구현한 객체b, 클래스b
인터페이스를 안정적으로 잘 설계하는게 엄청 중요하다.
좋은 객체 지향 설계의 5가지 원칙(SOLID)
클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리
- SRP(Single Resource)
단일 책임 원칙 : 하나의 클래스는 하나의 책임을 가져야 한다.
중요한 기준은 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙 - OCP (Open-Closed)
개방-폐쇄 원칙 : 확장에는 열려 있고 변경에는 닫혀있는
다형성과 관련된-> 스프링의 컨테이너가 이를 가능하게 한다.
다형성을 사용했지만 OCP를 지키지 못함
클라이언트인 MemberService는 구현 객체가 변경되면 코드를 수정해야 한다.
▶️해결책 : 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다 - 스프링 컨테이너
- LSP(LisKov substitution)
리스코프 치환 원칙 : 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
다형성과 관련된
하위 클래스는 인터페이스 규약을 다 지켜야 한다.
자동차 인터페이스의 악셀 앞으로 가라는 것
따라서 구현체의 악셀은 +10의 의미 O, -10의 의미 X - ISP(Interface segregation)
인터페이스 분리 원칙 : 특정 클라이언트를 위한 인터페이스 여러개 > 하나
자동차 인터페이스 -> 운전과 정비로 분리하여 두개의 인터페이스로
사용자 클라이언트 -> 운전자와 정비사 클라이언트로 분리 - DIP(Dependency inversion)
의존관계 역전 원칙 : 추상화에 의존 O, 구체화에 의존 X
로미엣 역할의 주인공 원빈은 김태희랑만 해서는 안되고 줄리엣 역할을 맡은 어느 사람이랑도 연극이 가능해야 한다.
이는 클라이언트는 구현체에 의존하지 않고 인터페이스에 의존해야 한다는 것이다.
여기서 클라이언트 MemberService는 인터페이스와 구현 클래스 모두에 의존한다. 🥲 이는 DIP 위반이다.
🕵️ 정리 🕵️
이 클라이언트 코드의 일부
다형성은 만족하나
OCP, DIP 를 지킬 수 없다 -> 객체 지향이 아니다
이를 해결해 주는 것은 스프링이다..🙂
객체 지향 설계와 스프링
스프링은 무엇인가? 왜 필요한가? 무엇을 가능하게 했는가?
이 물음의 답은 객체 지향 설계를 가능하게 했다는 것!
다형성+ OCP, DIP를 가능하게 지원
어떻게?
DI 컨테이너를 제공한다. 이는 자바 객체를 이 컨테이너 안에 넣고 거기 안에서 의존관계를 형성하도록 하는 것이다! 코드가 아닌!
즉, 클라이언트 코드의 변경 없이 기능 확장이 가능한 것이다.
🕵️ 정리 🕵️
- 모든 설계에 역할과 구현을 분리
- 따라서 인터페이스를 잘 구현하는 것이 중요
- 하지만 인터페이스를 도입하며 구현 클래스가 뭔지 코드에서는 확인이 불가능하므로 추상화라는 비용이 발생한다.
- 무조건 인터페이스를 만드는 것보다는 확장 가능성이 없다면 구현체 클래스를 직접 사용, 향후 확장 가능성이 있다면 인터페이스를 도입
