스프링이 뭐가 좋은지 직접 경험해보기 위해서 스프링 없이 순부 자바 코드로 서버 개발을 진행
Java 11
IntelliJ
자바 코드로 개발을 진행하고 이후 스프링으로 수정할 예정이기 때문에 스프링 부트로 프로젝트 생성하여 진행하였습니다.
비즈니스 요구사항
회원 가입
회원 조회
회원 등급 일반, VIP
회원 데이터 자체 DB 또는 외부 시스템과 연동
상품 주문
회원 등급에 따른 할인 정책
VIP는 1000원 할인
할인 정책 변경 가능
여기서 할인 정책과 회원 데이터는 변경될 수 있으므로 인터페이스를 만들고 이후 구현체를 교체할 수 있도록 설계
회원 도메인 설계
회원 서비스 : 회원 가입, 회원 조회
회원 저장소 : 회원 데이터에 접근하기 위한 인터페이스, 일단 인메모리로 개발하고 이후 데이터 관리방식이 결정되면 구현체 변경
문제점
private final MemberRepository memberRepository = new MemoryMemberRepository();dip 위반함
인터페이스 뿐만 아니라 구현체에도 의존을 하고 있음
AppConfig
생성자 주입
DI 의존관계 주입
5가지 원칙
SRP 단일 책임 원칙
한 클래스는 하나의 책임만 가져야 한다
DIP 의존관계 역전 원칙
프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
OCP
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
IoC
inversion of control
제어의 역전
기존 : 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고 연결하고 실행
AppConfig 사용 이후 : 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. AppConfig가 구현 객체를 생성 연결 실행
프로그램의 제어 흐름을 직접 제어하는 것이 아니라 AppConfig 처럼 외부에서 제어하는 것이 IoC
프레임워크 vs 라이브러리
프레임워크 : 프레임워크가 제어권을 가지고 있음 그것을 프레임워크가 대신 실행함
라이브러리 : 내가 작성한 코드가 코드에서 직접 제어의 흐름을 담당한다면 라이브러리
DI
의존관계 주입
의존관계는 정적인 클래스 의존 관계와 실행 시점에서 결정되는 동적인 객체 의존 관계를 구분
정적인 의존관계는 실행하지 않고도 분석 가능
IoC 컨테이너, DI 컨테이너
AppConfig 처럼 객체를 생성하고 연결해주는 것
스프링 컨테이너
ApplicationContext
기존에는 개발자가 AppConfig 직접 작성해서 DI
스프링 컨테이너는 @Configuration 이 붙은 AppConfig를 설정 정보로 사용한다
여기서 @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다
이전에는 개발자가 필요한 객체를 AppConfig를 사용해서 직접 조회했지만
스프링 컨테이너를 통해서 필요한 스프링 빈을 찾을 수 있다
아직은 그다지 장점이 없는거 같은데
스프링 컨테이너 사용했을때 장점은 ??
