스프링 & 객체지향 => 비로소 스프링의 핵심 가치를 제대로 이해 가능!
스프링의 핵심 가치 => 객체 지향 프로그래밍
<강의 목차>
1. 객체 지향 설계 & 스프링
2. 스프링 핵심 원리 이해 1 - 예제 만들기
3. 스프링 핵심 원리 이해 2 - 객체 지향 원리 적용
----------------
핵심 기능 (왜, 어디에, 실무에서는 어떻게)
4. 스프링 컨테이너 & 스프링 빈
5. 싱글톤 컨테이너
6. 컴포넌트 스캔
7. 의존관계 자동 주입
8. 빈 생명주기 콜백
9. 빈 스코프
<강의 목표>
스프링의 이유와 핵심 원리
- 스프링 기본 기능 학습
- 스프링 본질에 대한 깊은 이해
- 객체 지향 설계를 고민하는 개발자로 성장
1. 객체 지향 설계 & 스프링
ⓐ 스프링 탄생의 시대적 배경
자바 진영의 가장 중요+메인 기술 => 스프링 & JPA
a-1) 전설의 시작
로드 존슨 => 기존 EJB의 문제점 지적 -> +유겐 휠러, 얀 카로프 -> 스프링 탄생
'왜 열광했을까?'를 이해해보자 in 강의
a-2) 릴리즈
스프링 부트 => 스프링의 '설정이 힘들다'는 단점을 해결
리엑티브 프로그래밍 => 자바에서도 node.js처럼 비동기 논블로킹 개발 가능해짐
ⓑ 스프링이란?
b-1) 스프링 생태계
하나가 아닌 여러 가지 기술들의 모음
https://spring.io > Project > Overview 참고
핵심 : 스프링 프레임워크 & 스프링 부트
b-1-1) 스프링 프레임워크
핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타 등등 -- 이번 강의에서의 초점
b-1-2) 스프링 부트
스프링을 '편리하게' 사용할 수 있도록 지원
최근에는 모든 실무에 기본으로 사용
1) & 2)
=> 예전에는 스프링 가지고 프로젝트 하나를 하려면 빌드를 하고, Tomcat 서버를 받아서 별도로 설치를 하고, 또 그 Tomcat 서버의 특정 위치에 빌드한 스프링 프로젝트를 넣고, 띄우고 했었어야 했음
하지만 지금은 스프링 부트 덕에 빌드하고 서버 띄우는 것까지 자체적으로 코드 몇 줄로 해낼 수 있음
3)
=> 예전에는 스프링 프레임워크 쓰려면 이 라이브러리, 저 라이브러리 다 알아서 받아왔어야 하는데,
지금은 스프링 부트 OOO starter 덕분에 라이브러리 하나만 땡기면 그에 필요한 나머지 라이브러리들까지 같이 챙겨줌
4)
=> 현재 스프링 프레임워크 버전과 외부 라이브러리 버전 간의 궁합을 알아서 맞춰 구성해줌
5)
=> 운영 환경에서 모니터링 하는 것 굉장히 중요한데 그 기본 기능을 스프링 부트에서 제공해줌
6)
=> 예전에는 스프링 프레임워크의 '설정'이 정말 힘들었었는데,
스프링부트는 웬만한 것들이 default 설정으로 되어있고, 매뉴얼에 다 나와있어서 내게 꼭 필요한 설정을 조금만 변경시키면 됨
# '스프링'의 문맥?
스프링 =
- 스프링 DI 컨테이너 기술 <좁은 의미>
- 스프링 프레임워크
- 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계 <넓은 의미>
b-2) 스프링은 '왜' 만들었나?
잠깐 로드 존슨이 되어보자..
# 핵심 컨셉
= 이 기술을 왜 만들었는가?
=> 아무리 복잡한 기술도 핵심 컨셉은 정말 단순하게 시작했다! 근데 그 핵심 컨셉이 너무 좋아서 기술 생태계가 어마어마하게 커지게 되는 것
로드 존슨의 핵심 컨셉이 담긴 3만 줄의 핵심 코드로부터 시작
왜 개발자들이 이에 열광했을까
이것을 꼭 제대로 이해해야 한다!
그 핵심 컨셉에 대한 이해를 근간으로 해야, 그로 인해 파생된 기능들을 손쉽게 이해할 수 있음
이게 아니라면 그냥 API 사용법 정도만 깔짝깔짝 알게 되는 것임
스프링의 진짜 핵심
=> 자바 언어 기반의 프레임워크
=> 자바 - '객체 지향 언어'
=> 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
=> '좋은 객체 지향' 애플리케이션을 개발할 수 있게 도와주는 프레임워크
스프링 이전, EJB를 사용할 당시에는 EJB를 상속받고 하는 일련의 과정들이 너무 지저분했고, EJB에 의존적으로 개발하느라, 객체지향의 좋은 장점들을 다 잃어버리게 되었음.
그래서 순수한 자바, 순수한 객체지향으로 돌아가자는 'POJO'(Plain Old Java Object)로 돌아가자는 단어도 나올 정도였음.
ⓒ 좋은 객체 지향 프로그램이란?
c-1) 좋은 객체 지향 프로그래밍?
c-1-1) 객체 지향의 특징
- 추상화
- 캡슐화
- 상속
- 다형성
c-1-2) 객체 지향 프로그래밍
- "객체"들의 모임
- 객체 : 메세지 주고받고, 데이터를 처리함 ; 협력
- 유연 & 변경 용이
c-1-3) 유연 & 변경 용이?
=> 컴포넌트를 쉽고 유연하게 변경하면서 개발 가능
=> 객체지향의 '다형성'
c-2) 다형성 (Polymorphism)
c-2-1) 다형성 --> 실세계 비유
실세계와 객체 지향을 완전 1:1로 매칭하는 게 안 되긴 함
하지만 이해하기에는 좋음
세상을 '역할'(인터페이스) & '구현'(객체)으로 구분해보자
EX-1) 운전자--자동차
K3를 몰다가 아반떼를 몬다고 운전자에 영향을 주지 않음
=> 유연 & 변경 용이
How?
=> 자동차 역할의 인터페이스에 따라서 자동차 구현이 이뤄졌기 때문.
운전자는 인터페이스(자동차 역할)만 알고 의존하고 있음.
근데 왜 '역할' & '구현'을 "구분"했을까?
=> 클라이언트(운전자)를 위해.
클라이언트가 자동차의 내부 구조를 몰라도 되도록.
구현체들이 내부적으로 바뀌더라도 자동차의 역할에만 충실하다면 클라이언트에게 영향 안 줌
클라이언트가 구현체를 바꿔도 그대로 자동차 역할 수행 가능
=> 생태계 자체에 엄청난 변혁을 가져오지 않고도 구현의 확장이 가능하게 됨
=> 클라이언트에게 영향을 미치지 않고 새로운 기능을 제공할 수 있음
=> 새로운 구현체가 나왔다고 해서 클라이언트가 움직이거나 변할 필요가 없다는 거임
EX-2) 로미오--줄리엣
역할에 대한 '배우'는 대체가 가능해야 함
=> 대체가능성
=> 유연 & 변경 용이
c-2-2) 역할 & 구현의 분리
=> 단순 & 유연 & 변경 용이
# 장점
핵심 : "클라이언트"
- 클라이언트 : 대상의 인터페이스(역할)만 알면 된다
- 클라이언트 : 구현 대상의 내부 구조를 몰라도 된다
- 클라이언트 : 구현 대상의 내부 구조가 변경되어도 영향 받지 않는다
- 클라이언트 : 구현 대상 자체를 변경해도 영향 받지 않는다
# JAVA 언어
- 자바 언어의 '다형성'
- 역할 == 인터페이스
- 구현 == 인터페이스를 구현한 클래스, 구현 객체 - 객체를 설계할 때
- 역할 & 구현을 명확히 분리
- '역할'(인터페이스) 먼저 부여 --> 그 역할을 수행하는 '구현' 객체 만들기
- 핵심 : '역할'이 더 중요함!
- cf) 물론 인터페이스뿐만 아니라 일반 상속 관계에서도 다형성 가능함. 하지만 가급적이면 인터페이스가 더 나을 것. 왜냐하면 인터페이스는 다중으로 구현 가능하지만, 일반 상속은 단일 상속밖에 안 되는 문제 있기 때문.
# 한계
- 역할(인터페이스) 자체가 변하면, 클라이언트 & 서버 모두에 큰 변경이 발생한다
# 정리
- 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있음
- 유연 & 변경 용이
- 확장 가능한 설계
- 클라이언트에 영향을 주지 않는 변경 가능
- 인터페이스를 안정적으로 잘 설계하는 것이 중요 -- 제일 중요!!!
c-2-3) '객체의 협력'이라는 관계
- 혼자 있는 객체는 없다 ==> '클라이언트'의 존재!!!
- 클라이언트 : '요청' / 서버 : '응답'
- 수많은 객체 클라이언트 & 객체 서버는 서로 '협력' 관계를 가진다
(서버+클라이언트) 가능
'응답' : 꼭 return 값이 있어야 하는 건 아님. 내부적으로 그냥 print만 할 수도 있고, return 값이 void일 수 있음. 클라이언트에서 요청한 행위를 하는 것을 응답이라고 함
c-2-4) JAVA 언어의 다형성
'오버라이딩'
실행되는 건 오버라이딩 된 메서드
다형성 => 인터페이스를 구현한 객체를 '실행 시점'에 유연하게 변경 가능
(물론 클래스 상속 관계도 다형성, 오버라이딩 적용 가능)
MemberService는 MemberRepository를 의존함
'의존한다' : 내가 쟤를 알고 있다
MemberRepository 인터페이스를 구현한 MemoryMemberRepository와 JdbcMemberRepository를 할당
부모 타입으로 다 받을 수 있음
c-2-5) 다형성의 본질
- 인터페이스를 구현한 객체 인스턴스를 '실행 시점'에 '유연'하게 '변경'할 수 있다
- 다형성의 본질을 이해하려면 '협력'이라는 객체 사이의 '관계'에서 시작해야 한다
- '클라이언트'를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다
c-2-6) 스프링 & 객체 지향
- 객체지향 => '다형성'이 가장 중요
- 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다
- 스프링에서 이야기하는 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다
- 스프링을 사용하면 마치 레고 블럭 조립하듯이 구현을 편리하게 변경할 수 있다
그런데, 스프링 & 객체 지향에 대해 제대로 이해하려면 다형성 외에 또 알아야 하는 게 있음!
=> SOLID ; 좋은 객체 지향 설계의 5가지 원칙
면접에도 되게 잘 나오는 내용..
다형성 + SOLID => 스프링에 대해 제대로 설명 가능!
ⓓ 좋은 객체 지향 설계의 5가지 원칙 (SOLID)
d-1) SOLID
- 클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리
- SRP: 단일 책임 원칙(single responsibility principle)
- OCP: 개방-폐쇄 원칙 (Open/closed principle)
- LSP: 리스코프 치환 원칙 (Liskov substitution principle)
- ISP: 인터페이스 분리 원칙 (Interface segregation principle)
- DIP: 의존관계 역전 원칙 (Dependency inversion principle)
"S" - SRP : 단일 책임 원칙
Single Responsibility Principle
-
하나의 클래스는 하나의 책임만 가져야 한다
-
'하나의 책임' => 모호함..
- 클 수도, 작을 수도 있음
- 문맥과 상황에 따라 다르다
- 책임의 크기를 '적절히' 조정하는 것이 객체지향의 묘미 -
중요한 기준 => "변경"
변경이 있을 때 그 파급 효과가 적으면, 단일 책임 원칙을 잘 따른 것이다
"O" - OCP 개방-폐쇄 원칙
Open/Closed Principle
-
가장 중요한 원칙 2가지 ; OCP & DIP
-
소프트웨어 요소는 '확장'에는 열려 있으나, '변경'에는 닫혀 있어야 한다
(like 열림교회 닫힘...) -
'다형성'을 떠올려보자
- 인터페이스를 구현한 새로운 클래스를 만들어서 새로운 기능을 구현하는 것은 기존 코드를 변경하는 것이 아님
- 역할과 구현의 분리
# 문제점
- MemberService 클라이언트가 구현 클래스를 직접 선택해야 함
- 기존 코드 : MemberRepository m = new MemoryMemberRepository();
- 변경 코드 : MemberRepository m = new JdbcMemberRepository(); - 구현 객체(Repository)를 변경하려면 클라이언트(Service) 코드를 변경해야 한다
- 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없는 문제 발생...!
- 이 문제를 어떻게 해결해야 하나?
- 객체를 생성하고 연관관계를 맺어주는, 별도의 조립을 해주는 설정자가 필요!
=> '스프링 컨테이너' (DI, IoC 등등)
"L" - LSP 리스코프 치환 원칙
Liskov Substitution principle
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다
- 다형성에서 하위 클래스는 인터페이스 '규약'을 다 지켜야 한다는 것
- 다형성을 지원하기 위한 원칙
- 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다
- 단순히 컴파일에 성공하는 것을 넘어서는 이야기
- EX) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능. 뒤로 가게 구현하면 LSP 위반. 느리더라도 앞으로 가야함.
"I" - ISP 인터페이스 분리 원칙
Interface Segregation Principle
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
- 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
=> 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
=> 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음 - 인터페이스가 명확해지고, 대체 가능성이 높아진다
- 인터페이스도 기능을 적당한 크기로 쪼개는 게 좋다
"D" - DIP 의존관계 역전 원칙
Dependency Inversion Principle
-
가장 중요한 원칙 2가지 ; OCP & DIP
-
프로그래머는 "추상화"에 의존해야지, '구체화'에 의존하면 안 된다는 원칙을 따르는 방법 중 하나
-
클라이언트 : 구현 클래스(구현)에 의존하지 말고, '인터페이스(역할)'에 의존해야 함
- 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다! 구현체에 의존하게 되면 변경이 아주 어려워진다
# 문제점
-
OCP에서 설명한 MemberService는 인터페이스(MemberRepository)에 의존하지만, 구현 클래스(MemoryMemberRepository)도 동시에 의존한다(알고 있다)
=> DIP 위반 -- 추상화뿐만 아니라 구체화에도 의존하고 있다 -
MemberService 클라이언트가 구현 클래스를 직접 선택(의존)
- MemberRepository m = new MemoryMemberRepository();
# 정리
- 객체 지향의 핵심 => 다형성
- BUT 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다
- 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다
- 다형성 만으로는 OCP, DIP를 지킬 수 없다
- 뭔가 더 필요하다.. ↓↓↓↓
ⓔ 객체 지향 설계 & 스프링
e-1) 다시 '스프링'으로
e-1-1) 스프링 이야기에 왜 객체 지향 이야기가 나오는가?
- 스프링 : 다형성 + OCP & DIP를 가능하도록 지원!
- DI (Dependency Injection) : 의존관계, 의존성 주입
- DI 컨테이너 : 자바 객체들을 컨테이너 안에 넣어놓고, 그들 간의 의존관계들을 연결해주고 주입해주는 기능을 제공한다
=> 클라이언트 코드의 변경 없이, 쉽게 부품을 교체하듯이 기능 확장/개발 가능!!!
e-1-2) 스프링이 없던 시절로
- 옛날에 어떤 개발자가 좋은 객체 지향 개발을 위해 OCP, DIP 원칙을 지키면서 개발을 해보니, 너무 할일이 많아 배보다 배꼽이 큰 수준이었다. 그래서 프레임워크로 만들어버림!
=> 순수하게 자바로 OCP, DIP 원칙들을 지키면서 개발을 해보면, 결국 '스프링 프레임워크'(더 정확히는 '스프링 DI 컨테이너')를 만들게 된다
- DI 개념은 말로 설명해도 이해가 잘 안된다. 코드로 짜봐야 필요성을 알게된다!
- 다음 강의부터는 스프링이 "왜?" 만들어졌는지 코드로 이해해볼 예정
# 정리
- 모든 설계에 '역할'과 '구현'을 분리하자 => 좋은 객체 지향 설계 => 다형성 + OCP & DIP --> 스프링 컨테이너
- 이상적으로는 모든 설계에 인터페이스를 부여하는 게 좋음
- 장점 :
기술적으로는 어떤 DB를 쓸지, 기획적으로는 어떤 할인 정책을 실시할지 아직 정해지지 않은 상황에서 일단 인터페이스 정도만 개발해놓고 하부의 구현 기술에 대한 선택 및 확장은 최대한 미룰 수 있고, 나중에 구현 기술이 바뀌더라도 변경의 범위가 작고 유연해질 수 있음
## 실무 고민
- BUT 인터페이스를 너무 무분별하게 남발하면 '추상화'라는 비용이 발생한다
- 코드를 한 번 더 까봐야 함 - 항상 어떤 방법의 장점이 단점을 넘어설 때, 그 방법을 채택해야 한다
- 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이다 -- 좋은 아키텍처 개발자들이 선택할 사항
2. 스프링 핵심 원리 이해 1 - 예제 만들기
역할과 구현 나누어 순수한 자바로(스프링의 도움 없이) 만들어볼 예정
=> 요구사항이 나중에 실제로 변경됐을 때 정말 유연하게 대처 가능한가 ; 다형성, OCP, DIP가 잘 지켜지는가
문제가 있다면 '스프링 핵심 원리 이해 2'에서 객체 지향 원리를 적용해가며 해결할 예정
<목차>
- 프로젝트 생성
- 비즈니스 요구사항과 설계
- 회원 도메인 설계
- 회원 도메인 개발
- 회원 도메인 실행과 테스트
- 주문과 할인 도메인 설계
- 주문과 할인 도메인 개발
- 주문과 할인 도메인 실행과 테스트
① 프로젝트 생성
프로젝트 세팅을 할 때는 스프링 부트를 사용하면 편하고 나중에 '스프링 핵심 원리 이해 2'에서 관련 라이브러리도 사용할 예정이기 때문에 사용하겠음
SNAPSHOT이나 M 버전은 아직 정식 릴리즈된 버전이 아님
② 비즈니스 요구사항과 설계
- 회원
- 회원을 가입하고 조회할 수 있다.
- 회원은 일반과 VIP 두 가지 등급이 있다.
- 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정) - 주문과 할인 정책
- 회원은 상품을 주문할 수 있다.
- 회원 등급에 따라 할인 정책을 적용할 수 있다.
- 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.)
- 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정)
요구사항을 보면 회원 데이터, 할인 정책 같은 부분은 지금 결정하기 어려운 부분이다. 그렇다고 이런 정책이 결정될 때 까지 개발을 무기한 기다릴 수도 없다.
하지만 우리에게는 앞에서 배운 객체 지향 설계 방법이 있다!
인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계하면 된다.
cf) 프로젝트 환경설정을 편리하게 하려고 스프링 부트를 사용한 것이다. 지금은 스프링 없는 순수한 자바로만 개발을 진행한다는 점을 꼭 기억하자! 스프링 관련은 '스프링 핵심 원리 이해 2'에서 등장한다.
③ 회원 도메인 설계
DB, 외부 시스템 모두 미결정 상태..
메모리 회원 저장소라도 일단 개발 진행 -- 테스트용으로..
i) 회원 도메인 협력 관계
=> 기획자들도 볼 수 있는 그림
ii) 회원 클래스 다이어그램
=> '회원 도메인 협력 관계'을 바탕으로 개발자들이 구체화한 그림
인터페이스와 구현체들이 다 보임
iii) 회원 객체 다이어그램
- '클래스' 다이어그램
=> 서버를 실행하지 않고 클래스만 구성해서 볼 수 있는 그림 - '객체' 다이어그램
=> 구현체들은 서버가 뜰 때 동적으로 결정되기 때문에 클래스 다이어그램만으로는 파악이 힘들고 객체 다이어그램을 따로 구성해야 함. 실제 서버가 떠서 클라이언트가 사용하는 MemberServiceImpl, 메모리 회원 저장소.
④ 회원 도메인 개발
인터페이스랑 구현체는 웬만하면 '다른' 패키지에 두는 게 좋음
(여기서는 그러면 복잡해지니까 그냥 같은 패키지에 두겠음)
복잡해지는 걸 막기 위해 오류 처리 로직은 좀 생략하겠음
cf) HashMap 은 동시성 이슈가 발생할 수 있어, 원래는 ConcurrentHashMap 을 사용해야 한다
구현체 하나만 있을 때는 MemberServiceImpl처럼 "Impl"을 이름에 써주는 게 관행
⑤ 회원 도메인 실행과 테스트
우리가 만든 회원 도메인이 정상적으로 돌아가는지 만들어보고 테스트 해볼 예정
- 클래스 다이어그램 => 정적
- 객체 다이어그램 => 동적(런타임)
psvm => public static void main(String[] args) { ... }
soutv => println 변수 선택 가능
1L => Long 타입
JUnit이라는 테스트 프레임워크를 사용할 예정
//given 주어지는 것
//when 언제
//then 그러면
규칙
검증 => Assertions
# 'main에서 test 코드 작성' VS 'test에서 test 코드 작성'
- main에서 test 코드 작성 => 애플리케이션 로직으로 테스트 하는 것은 좋은 방법이 아니다. 왜냐하면 검증을 '눈으로' 해야 하기 때문
- test에서 test 코드 작성 => 콘솔에 출력된 결과로써 검증 가능
test는 더이상 선택이 아닌 필수!
# 회원 도메인 설계의 문제점
이 코드의 설계상 문제점은 무엇일까?
- 다른 저장소로 변경할 때 OCP 원칙을 잘 준수할까?
- DIP를 잘 지키고 있을까?
=> 의존관계가 인터페이스(추상화) 뿐만 아니라 구현(구체화)까지 모두 의존하는 문제점이 있음
-- 주문(Order)까지 만들고나서 문제점과 해결 방안을 설명 예정
⑥ 주문과 할인 도메인 설계
<주문과 할인 정책>
- 회원은 상품을 주문할 수 있다.
- 회원 등급에 따라 할인 정책을 적용할 수 있다.
- 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.)
- 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정)
i) 주문 도메인 협력+역할+책임 --only 역할만
- 주문 생성: 클라이언트는 주문 서비스에 주문 생성을 요청한다.
- 회원 조회: 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회한다.
- 할인 적용: 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다.
- 주문 결과 반환: 주문 서비스는 할인 결과를 포함한 주문 결과를 반환한다.
cf) 실제로는 주문 데이터를 DB에 저장하겠지만, 예제가 너무 복잡해 질 수 있어서, 단순히 주문 결과를 반환만 하고, DB에 저장하는 과정은 생략하겠음.
ii) 주문 도메인 전체 --역할+구현 (핵심 그림!)
역할 먼저 만들고 구현을 그 다음에 만듦
역할 & 구현 분리 => 자유롭게 구현 객체를 조립하면서 변경할 수 있도록 설계 가능
iii) 주문 도메인 '클래스' 다이어그램
iv) 주문 도메인 '객체' 다이어그램 (2가지)
회원 조회 방식(메모리/DB) & 할인 적용 정책(정액/정률)을 변경해도 주문 서비스를 변경하지 않아도 된다.
역할들의 협력 관계를 그대로 재사용 할 수 있다.
-- 이와 관련해서 책 '객체지향의 사실과 오해'(조영호)이 정말 잘 설명하고 있으니 참고해볼 것
⑦ 주문과 할인 도메인 개발
cf) 유용한 단축키
- F2 => 오류난 곳으로 바로 이동
- alt + enter => 애매할 땐 웬만하면..
enum 타입은 "=="으로 동등 비교하는 거 맞음
toString()
=> order 출력 시 이게 출력됨. 출력 내용을 보기 쉽게 하기 위함
(generate 옵션으로 생성 가능)
@Override
public String toString() {
return "Order{" +
"memberId=" + memberId +
", itemName='" + itemName + '\'' +
", itemPrice=" + itemPrice +
", discountPrice=" + discountPrice +
'}';
}createOrder() 메소드 =>
여기서 '1. 주문 생성' & '4. 주문 결과 반환' 담당
OrderServiceImpl
=> memberRepository & discountPolicy, 이렇게 2개 필요
int discountPrice = discountPolicy.discount(member, itemPrice);SRP(단일 책임 원칙) 굉장히 잘 지켜지도록 설계되어있음
order 입장에서는 discount에 대해 모르니까 discountPolicy 쪽으로 넘기면 됨
⑧ 주문과 할인 도메인 실행과 테스트
long(primitive 타입)이 아닌 Long을 굳이 쓰는 이유는, long의 경우 null 값이 들어가지 못함. 그래서 wrapper class 타입을 쓰는 거임.
단위 테스트 ('without 스프링' test)는 수 천 개가 있어도 몇 초만에 끝남.
그래서 단위 테스트를 잘 만드는 게 정말 중요.
다음 시간 :
지금 '다형성'은 잘 적용된 상태 (역할 <-> 구현)
근데 진짜 다형성만으로 회원 조회 방식(메모리/DB) 또는 할인 적용 정책(정액/정률)을 변경했을 때, 클라이언트에 영향을 주지는 않는가? 정말 우리가 개발한 게 객체지향적으로 잘 개발된 게 맞을까?
