발자국남기기

테코톡 스터디 : Spring IoC/DI 10분 테코톡을 시청하고 작성하였습니다. 영상링크 참고용 : 이전에 영한님 강의듣고 정리해놓은 IoC/DI 스프링의 대 삼각형 스프링의 가장 밑바탕이 되는 3가지 IoC/DI ==> 가장 기본 AOP PSA IoC / DI Spring Framework의 근간 Object의 생명주기와 의존관계에 대한 프로그래밍 모델 유연하고 확장성이 뛰어난 코드를 만들 수 있게 해주는 프로그래밍 모델 "토비의 스프링"에서 발췌 관심사의 분리 유연하고 확장성이 뛰어나다. (= 변경이 있을 때 수정이 쉽다.) (= 수정할 부분만 수정하면 된다.) (= 관심사의 분리가 잘 이루어졌다.) 전략 패턴(Strategy Pattern) 관심사의 분리를 잘 설명할 수 있는 패턴 객체들이 할 ..

웹 스코프는 웹 환경에서만 동작하고, 스프링이 해당 스코프의 종료시점까지 관리하므로 종료 메서드가 호출된다. 웹 스코프 종류 request : HTTP요청 하나가 들어오고 나갈 때까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리된다. session : HTTP Session과 동일한 생명주기를 가지는 스코프 application : 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프 websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프웹 환경에서만 동작하고, 스프링이 해당 스코프의 종료시점까지 관리하므로 종료 메서드가 호출된다. 클라이언트 A와 B는 서로 다른 빈 인스턴스를 가지게된다. request 스코프 만들기 웹 환경 추가 웹 ..

의도적으로 해당 타입의 스프링 빈이 다 필요한 경우도 있다. 예를 들어, 할인 서비스를 제공하는데 클라이언트가 할인의 종류를 선택할 수 있다면? 스프링을 사용하여 해결해보자. 위와 같이 테스트 코드를 작성하였다. 전에 만들어놓았던 AutoAppConfig를 통하여 컴포넌트 스캔을 진행하여 스프링 빈으로 등록한다.(@Component가 붙은 클래스 모두 등록) 그리고 우리가 static으로 만든 DiscountService또한 스프링 빈으로 등록시키는데 의존관계 주입시 List와 Map형태로 RateDiscountPolicy와 FixDiscountPolicy를 주입할 것이다. 테스트를 실행시켜보면 다음과 같이 Map와 List에 조회된 모든 빈들이 들어가있고, discountService 또한 정상적으로 ..

과거에는 수정자 주입과 필드 주입을 많이 사용했지만, 최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다. 불변 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변) 수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 한다. 누군가 실수로 변경할 수도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아님 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계 가능 누락 프레임워크 없이 순수한 자바 코드를 단위 테스트 하는 경우에(수정자 주입을 사용) 아무런 오류가 발생하지 않지만 막상..

의존관계 주입은 크게 4가지가 있다. 1. 생성자 주입 2. 수정자 주입(setter 주입) 3. 필드 주입 4. 일반 메서드 주입 생성자 주입 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법이다. 지금까지 진행했던 방법이 바로 생성자 주입 특징 생성자 호출 시점에 딱 1번만 호출되는 것이 보장 불변, 필수 의존관계에 사용 불변 한번 생성되면 바뀌지 않음 간단히 말하여 변할 수 없게 setter와 같이 수정할 수 있는 메소드를 만들지 않아야함 필수 관례적으로 생성자에는 값을 다 채워넣어야함. null을 허용한다고 명시되어있는 것이 아닌 경우에는 생성자가 딱 1개만 @Autowired를 생략해도 자동 주입된다.(스프링 빈에만 해당) 수정자 주입(setter 주입) setter라 불리는 필드의 값을..

제어의 역전 - IoC (Inversion of Control) 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한 마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다. 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호 출하지만 어떤 구현 객체들이 실행될지 모른다. 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다. 심지어 OrderServiceImpl 도 AppConfig가 생성한다. 그리고 AppCo..

현재 AppConfig에는 중복이 있고, 역할에 따른 구현이 잘 보이지 않는다. MemoryMemberRepository가 중복되어 사용되고 있음. 메소드로 꺼내어 사용 또한 어떤 역할(인터페이스)를 사용하여 구현을 했는지가 보이지 않는다. MemoryMemberRepository는 MemberRepository의 역할을 수행하는데 그것을 확인할 수 없음. 👇 👇 다음과 같이 중복을 제거하고 메소드를 추출하였다 어떤 역할(인터페이스)에서 어떤 구현체를 사용한 것인지 한 눈에 확인할 수 있다. 이는 만약 회원 저장소가 변경될 때 (DB를 사용하거나 jdbc를 연동할 때) memberRepository안의 구현체만 변경해주면 된다. 전체 애플리케이션의 구성이 어떻게 되어있는지 파악가능 정액 할인을 정률 할인..

현재 작성된 코드는 주문서비스 구현체(OrderServiceImpl)가 할인 정책 구현체를 선택하고 있는 상태이다. (FixDiscountPolicy / RateDiscountPolicy) 이를 공연에 대입해보자. 공연은 각 배역이 있고 그에 맞는 배우가 있다. 이를 매칭시켜보면 공연 = 애플리케이션(비지니스 로직 전체) 배역 = 인터페이스 (OrderService, DiscountPolicy) 배우 = 구현체 (OrderService, FixDiscountPolicy / RateDiscountPolicy) 배우가 상대 배역의 배우를 선택하고 있는 것과 똑같은 상황이라 할 수 있다. 즉, 배우가 공연도 해야하고 상대 배역까지 정해야하는 다양한 책임을 가지고 있음. 즉, 우리에게는 공연 기획자같은 역할에 ..

스프링 빈과 의존관계 스프링 빈을 등록하고, 의존관계 설정하기 생성자에 @Autowired 가 있으면 스프링이 연관된 객체를 스프링 컨테이너에서 찾아서 넣어준다. 이렇게 객체 의존관계를 외부에서 넣어주는 것을 DI (Dependency Injection), 의존성 주입이라 한다. 이전 테스트에서는 개발자가 직접 주입했고, 여기서는 @Autowired에 의해 스프링이 주입해준다 스프링 컨테이너(Spring Container)에 의해서 자바 객체가 만들어 지게 되면 이 객체를 스프링은 스프링 빈이라고 부름. 등록방법에는 아래 두가지 방법이 있다. 컴포넌트 스캔과 자동 의존관계 설정 @ComponentScan 어노테이션은 어느 지점부터 컴포넌트를 찾으라고 알려주는 역할 @Component는 실제로 찾아서 빈에..

Test given 주어지는 것 when 주어졌을 때 then 어떻게 되는지 1. 회원가입 테스트 (join) given member에 name은 hello when member를 join시킴 id값이 return되므로 saveId에 저장 then return되어 저장된 saveId를 가지고 repository에 저장되어 있는 member정보 가져옴. 그것을 우리가 생성한 member객체의 name과 비교 성공 테스트에서 가장 중요한 것은 반례, 즉 예외 case이다. 1-2. 회원가입 테스트 (join) - 중복 회원 가입 try - catch문을 통하여 오류를 받고 메세지 비교를 통해 테스트 검증 성공 * assertThrows메소드를 활용해 더 간단하게 테스트하기 memberService.join(..