To Do
- 스프링 핵심 원리 - 기본편 / 섹션2 ~섹션3
프로젝트 주제 : 회원 서비스와 상품 구매 시 할인 적용
정리 내용은 크게 3가지로 정리된다.
1. 섹션 2-첫 강의 ~ 섹션3-관심사의 분리 전까지 (순수한 자바 코드, 스프링 사용 X)
처음 프로젝트 생성부터 간단한 회원 가입, 조회 로직과 상품 주문 서비스 구현.
하지만 앞에서 배운 DIP(의존 관계 역전 원칙), OCP(개방-폐쇄 원칙)이 지켜지지 않는다.
위의 원칙이 지켜지지 않은 이유는 아래의 코드에서

OrderServiceImpl가 인터페이스인 DiscountPolicy뿐 만 아니라
각각의 구체 클래스까지 의존하고 있다. (DIP 위반)
원래는 인터페이스에만 의존해야 하고 구체 클래스는 뭐가 된든지 몰라야 한다.
할인 정책을 바꿀 때 코드를 변경해야 한다. 즉, 클라이언트가 이를 알아야 하며 영향을 준다. (OCP 위반)
정리
-> OCP, DIP 원칙을 위반한 코드를 구현함. 객체지향적 X (스프링 사용 X, 순수한 자바코드)
2. 섹션3-관심사의 분리 ~ 섹션3-스프링으로 전환하기 전까지 (순수한 자바코드, 스프링 사용X)
1번에서 발생했던 객체지향 원칙 위반을 해결하기 위해
AppConfig를 생성한다. 이때 AppConfig의 역할은 구성 영역에서 전체 애플리케이션의 동작 방식을 구성한다.
AppConfig에서 구현 객체를 생성하고 연결한다. (코드를 보면 이해 가능)
(즉, 앱의 전체적인 실행을 AppConfig에서 조작하고 나머지 클라이언트들은 인터페이스에만 의존하게 된다.
그 안에 구현 클래스가 정률 할인이든...고정 할인이든... 상관ㄴㄴ)
코드를 살펴보면

AppConfig에서 생성한 구현 객체를 각각의 클라이언트에 연결해 준다.
할인 정책도 딱 이 부분에서 바꿔주면 다른 모든 코드가 알아서 돌아간다.

OrderService에는 오로지 인터페이스만 들어가 있다. (무슨 할인 정책인지, 무슨 회원 저장소인지 몰라도 들어오는 데로 실행ㄱ)

실행하는 곳에서는 AppConfig 객체를 만들어서 연결해 준다!!
-IoC (Inversion of Control) 제어의 역전
AppConfig를 이용할 때 OrderServiceImpl처럼 필요한 인터페이스는 호출하지만 오직 로직을 실행할 뿐
어떤 구현 객체가 실행될지 모르는 것처럼
어떤 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부(AppConfig)에서 관리하는 것을 IoC (제어의 역전)이라고 한다.
- DI (Dependency Injection) 의존관계 주입
OrderServiceImpl이 DiscountPolicy인터페이스에만 의존하는 것처럼
정적인 클래스 의존 관계(인터페이스 의존)와 동적인 객체 의존 관계(실행시점에서 결정되는 실제 구현 객체)를
분리해서 생각할 수 있어야 한다.
정리
-> AppConfig라는 기획자를 만들어서 관심사를 분리해 준다.
즉 클라이언트는 무슨 구체 클래스인지 신경 쓰지 않고 AppConfig에서 넣어준 구현 객체를 넣어서 실행할 뿐
인터페이스에만 의존하게 된다.
이 과정으로 DIP, OCP를 포함한 SOLID 원칙이 모두 지켜졌다.
AppConfig처럼 객체를 생성하고 관리하면서 의존 관계를 연결해 주는 것은 IoC 컨테이너 또는 DI 컨테이너라고 한다.
(스프링 사용 X, 순수한 자바코드)
3. 섹션3-스프링으로 전환하기 (스프링 사용)
위의 2번까지는 개발자가 AppConfig에서 직접 객체를 생성하고 DI를 했다.
지금부터는 스프링 컨테이너를 생성하여 객체들을 관리한다.

@Configuration으로 스프링 컨테이너를 생성한다.
@Bean이 달린 메서드를 객체로 생성하여 스프링 컨테이너에 담아준다. (이런 객체를 스프링 빈이라고 한다.)
이때 메서드명을 스프링 빈의 이름으로 하는 게 일반적인다. (위에서는 스프링 빈의 이름이 "memberService"이다.)
이제부터는 개발자가 직접 객체를 조작하는 것이 아닌 필요한 객체를 스프링 컨테이너에 등록하고 스프링 빈(객체)를 사용한다.
사용 예시는 아래와 같다.

2번에서 구현한 모든 코드들에 스프링(스프링 컨테이너 생성 후 스프링 빈 등록)을 사용한 코드로 바꿔주었다.
보기에는 이름도 길어 보이고 더 복잡해 보이는 이 스프링을 사용하는 이유와 장점은 무엇일까?
---> 이 부분은 섹션4부터 알 수 있다.
생각 정리
섹션2~섹션3에는 이 강의의 전체적인 흐름이 담겨있다고 생각했다.
모든 기본 내용의 토대가 되는 중요한 내용이라고 생각되었기 때문에 완전히 이해하고 꼼꼼히 기록하고 싶었다.
처음 순수한 자바 코드에서 객체지향 원칙 적용, 스프링 적용까지의 흐름이 잘 이해되고 재미있어서
옛날에 스프링 없이 개발하던 개발자의 느낌도 느껴볼 수 있었다.
빠르지만 완벽하게 완강 기릿 해야겠다. (진도 매우 밀림)

'TIL & 일기 > TIL' 카테고리의 다른 글
TIL - 2023/07/05 (0) | 2023.07.07 |
---|
To Do
- 스프링 핵심 원리 - 기본편 / 섹션2 ~섹션3
프로젝트 주제 : 회원 서비스와 상품 구매 시 할인 적용
정리 내용은 크게 3가지로 정리된다.
1. 섹션 2-첫 강의 ~ 섹션3-관심사의 분리 전까지 (순수한 자바 코드, 스프링 사용 X)
처음 프로젝트 생성부터 간단한 회원 가입, 조회 로직과 상품 주문 서비스 구현.
하지만 앞에서 배운 DIP(의존 관계 역전 원칙), OCP(개방-폐쇄 원칙)이 지켜지지 않는다.
위의 원칙이 지켜지지 않은 이유는 아래의 코드에서

OrderServiceImpl가 인터페이스인 DiscountPolicy뿐 만 아니라
각각의 구체 클래스까지 의존하고 있다. (DIP 위반)
원래는 인터페이스에만 의존해야 하고 구체 클래스는 뭐가 된든지 몰라야 한다.
할인 정책을 바꿀 때 코드를 변경해야 한다. 즉, 클라이언트가 이를 알아야 하며 영향을 준다. (OCP 위반)
정리
-> OCP, DIP 원칙을 위반한 코드를 구현함. 객체지향적 X (스프링 사용 X, 순수한 자바코드)
2. 섹션3-관심사의 분리 ~ 섹션3-스프링으로 전환하기 전까지 (순수한 자바코드, 스프링 사용X)
1번에서 발생했던 객체지향 원칙 위반을 해결하기 위해
AppConfig를 생성한다. 이때 AppConfig의 역할은 구성 영역에서 전체 애플리케이션의 동작 방식을 구성한다.
AppConfig에서 구현 객체를 생성하고 연결한다. (코드를 보면 이해 가능)
(즉, 앱의 전체적인 실행을 AppConfig에서 조작하고 나머지 클라이언트들은 인터페이스에만 의존하게 된다.
그 안에 구현 클래스가 정률 할인이든...고정 할인이든... 상관ㄴㄴ)
코드를 살펴보면

AppConfig에서 생성한 구현 객체를 각각의 클라이언트에 연결해 준다.
할인 정책도 딱 이 부분에서 바꿔주면 다른 모든 코드가 알아서 돌아간다.

OrderService에는 오로지 인터페이스만 들어가 있다. (무슨 할인 정책인지, 무슨 회원 저장소인지 몰라도 들어오는 데로 실행ㄱ)

실행하는 곳에서는 AppConfig 객체를 만들어서 연결해 준다!!
-IoC (Inversion of Control) 제어의 역전
AppConfig를 이용할 때 OrderServiceImpl처럼 필요한 인터페이스는 호출하지만 오직 로직을 실행할 뿐
어떤 구현 객체가 실행될지 모르는 것처럼
어떤 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부(AppConfig)에서 관리하는 것을 IoC (제어의 역전)이라고 한다.
- DI (Dependency Injection) 의존관계 주입
OrderServiceImpl이 DiscountPolicy인터페이스에만 의존하는 것처럼
정적인 클래스 의존 관계(인터페이스 의존)와 동적인 객체 의존 관계(실행시점에서 결정되는 실제 구현 객체)를
분리해서 생각할 수 있어야 한다.
정리
-> AppConfig라는 기획자를 만들어서 관심사를 분리해 준다.
즉 클라이언트는 무슨 구체 클래스인지 신경 쓰지 않고 AppConfig에서 넣어준 구현 객체를 넣어서 실행할 뿐
인터페이스에만 의존하게 된다.
이 과정으로 DIP, OCP를 포함한 SOLID 원칙이 모두 지켜졌다.
AppConfig처럼 객체를 생성하고 관리하면서 의존 관계를 연결해 주는 것은 IoC 컨테이너 또는 DI 컨테이너라고 한다.
(스프링 사용 X, 순수한 자바코드)
3. 섹션3-스프링으로 전환하기 (스프링 사용)
위의 2번까지는 개발자가 AppConfig에서 직접 객체를 생성하고 DI를 했다.
지금부터는 스프링 컨테이너를 생성하여 객체들을 관리한다.

@Configuration으로 스프링 컨테이너를 생성한다.
@Bean이 달린 메서드를 객체로 생성하여 스프링 컨테이너에 담아준다. (이런 객체를 스프링 빈이라고 한다.)
이때 메서드명을 스프링 빈의 이름으로 하는 게 일반적인다. (위에서는 스프링 빈의 이름이 "memberService"이다.)
이제부터는 개발자가 직접 객체를 조작하는 것이 아닌 필요한 객체를 스프링 컨테이너에 등록하고 스프링 빈(객체)를 사용한다.
사용 예시는 아래와 같다.

2번에서 구현한 모든 코드들에 스프링(스프링 컨테이너 생성 후 스프링 빈 등록)을 사용한 코드로 바꿔주었다.
보기에는 이름도 길어 보이고 더 복잡해 보이는 이 스프링을 사용하는 이유와 장점은 무엇일까?
---> 이 부분은 섹션4부터 알 수 있다.
생각 정리
섹션2~섹션3에는 이 강의의 전체적인 흐름이 담겨있다고 생각했다.
모든 기본 내용의 토대가 되는 중요한 내용이라고 생각되었기 때문에 완전히 이해하고 꼼꼼히 기록하고 싶었다.
처음 순수한 자바 코드에서 객체지향 원칙 적용, 스프링 적용까지의 흐름이 잘 이해되고 재미있어서
옛날에 스프링 없이 개발하던 개발자의 느낌도 느껴볼 수 있었다.
빠르지만 완벽하게 완강 기릿 해야겠다. (진도 매우 밀림)

'TIL & 일기 > TIL' 카테고리의 다른 글
TIL - 2023/07/05 (0) | 2023.07.07 |
---|