Backend (46) 썸네일형 리스트형 [Spring] 스프링 컨테이너와 빈 1) 스프링 컨테이너 생성 목차 스프링 컨테이너 생성 컨테이너에 등록된 모든 빈 조회 스프링 빈 조회 - 기본 스프링 빈 조회 - 동일한 타입이 둘 이상 스프링 빈 조회 - 상속 관계 BeanFactory와 ApplicationContext 다양한 설정 형식 지원 - 자바 코드, XML 스프링 빈 설정 메타 정보 - BeanDefinition 스프링 컨테이너 생성 과정 *컨테이너 :사용하는 객체를 담고있는 것 다음 코드로 스프링컨테이너가 생성된다. ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); AppConfig 클래스를 파라미터로 넘기면, ApplicationContext를 반환해준다. Applicatio.. [Spring] 스프링으로 변경 2) ApplicationContext와 Bean 이제 AppConfig처럼 개발자가 직접 구현하는 것이 아닌 스프링에서 제공하는 DI컨테이너를 이용해 볼 것이다. AppConfig 스프링 기반으로 수정 AppConfig package hello.core; import hello.core.discount.DisountPolicy; import hello.core.discount.FixDiscountPolicy; import hello.core.discount.RateDiscountPolicy; import hello.core.member.MemberRepository; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import hello.core.me.. [Spring] 스프링으로 변경 1) IoC, DI, 컨테이너 스프링에만 국한된 단어는아니다. IoC (Conversion of Control) 제어의 역전 보통은 개발자가 원하는대로 객체를 생성 호출 , 호출한 객체 내에서 또 객체를 생성 호출 한다. (변경 이전의 코드를 떠올리자) 프레임워크 같은 것이 내 코드를 대신 호출해주면, 제어의 역전이 일어난 것(제어권이 뒤바뀜) 지금 까지는 구현 객체가 스스로 필요한 객체를 생성하고 생성했다. 구현체가 프로그램의 제어 흐름을 스스로 조정했다(개발자 입장에서는 자연스러운 흐림) 반면에 AppConfig등장 이후, 구현 객체는 자신의 로직을 실행하는 역할만을 담당하고(관심사의 분리) 프로그램의 제어 흐름은 이제 AppConfig가 가져가 담당한다. 예를들어 구현객체인 OrderServiceImpl은 필요한 인터페이스들을 .. [Spring] 순수 자바의 문제와 해결 3) 요구사항 변경 반영(OCP) So far... 우리는 지금까지 순수 자바코드를 이용하여 시스템을 개발하였다 (순수 자바예제1~3) 기획자로 부터 변경사항을 전달받아, 구현체의 변경을 시도하던 중 코드상에서 DIP/OCP문제점을 발견하였다.(순수 자바의 문제와 해결 1) 그리고 이 문제를 관심사 분리(appConfig)로 해결하였다 ( 순수 자바의 문제와 해결 2) 이제 기획자로 부터 받은 변경사항을 수정해줄 차례이다. 요구사항이 무엇이었는지 다시 한번 확인해보자 요구사항 변경 기획자가 오픈을 앞두고 프로그램의 변경을 요구한 상황이다. 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하든 200.. [Spring] 순수자바의 문제와 해결 2) 관심사의 분리(SRP/DIP) 관심사의 분리 관심사의 분리란 하나의 역할(인터페이스)은 하나(자신)의 역할 수행에만 집중해야함을 의미한다. 비유를 먼저 해보면, 애플리케이션 : 공연 인터페이스 : 배역(배우 역할) 구현체 : 배역에 캐스팅된 배우 라고 하자. 실제 배역에 맞는 배우를 캐스팅하는 것은 누구인가? "캐스팅 담당자"가 따로 존재한다. 이전 까지의 코드는 마치, 로미오 역할에 디카프리오(구현체)가 줄리엣 역할의 배우를 직접 섭외하는 것과 같은 상태였다. 이렇게 되면, 배우라는 구현체는 "연기"라는 관심사 주요 역할에서 벗어나, 누군가를 캐스팅하는 다양한 책임이 부여된다. 이는 올바른 상태가 아니다. 배우 디카프리오(구현체)는 "연기(역할)"에만 집중해야하며, 상대 배우로 누가 캐스팅되던지 (의존하는 인터페이스의 구현체가 무엇.. [Spring] 순수 자바의 문제와 해결 1) OCP/DIP위반 요구사항 변경 기획자가 오픈을 앞두고 프로그램의 변경을 요구한 상황이다. 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문시 1000원을 할인해주고, 20000원 주문시에 2000원을 할인해주는 거에요! 고정 금액 할인정책을 변경하고 싶다고 한다. 개발자는 이에 대비하여 "유연한 설계가 가능하도록 객체지향 설계 원칙을 준수했다" 할인을 해준다는 역할에는 변화가 없으니, RateDiscountPolicy 구현체를 제작해서, 이로 변경만 해주면.. [Spring] 순수 자바 예제 3) - 주문/할인 도메인 개발&테스트 프로젝트 생성 비즈니스 요구사항과 설계 회원 도메인 설계 회원 도메인 개발 회원 도메인 실행과 테스트 주문과 할인 도메인 설계 주문과 할인 도메인 개발 주문과 할인 도메인 실행과 테스트 주문과 할인 도메인 개발 이전 게시글의 주문과 할인 도메인 설계를 기반으로 개발을 진행한다. 할인 도메인 개발 core의 하위에 discount 패키지를 만든다. DiscountPolicy (인터페이스) 할인 정책 역할에 대한 인터페이스를 만든다. 할인이 얼마나 들어갈지 금액을 반환한다. package hello.core.discount; import hello.core.member.Member; public interface DisountPolicy { /** * * @param member * @param price .. [Spring] 순수 자바 예제 2) - 회원 도메인 개발&테스트 프로젝트 생성 비즈니스 요구사항과 설계 회원 도메인 설계 회원 도메인 개발 회원 도메인 실행과 테스트 주문과 할인 도메인 설계 주문과 할인 도메인 개발 주문과 할인 도메인 실행과 테스트 회원 도메인 개발 이전 게시글의 설계대로 개발을 해볼 차례다. 인터페이스 '어떤 역할'을 수행할 것인지 명시하는 인터페이스 회원관련 서비스의 역할을 하는 MemberService Interface 회원관련 데이터를 저장하고, 데이터에 접근하여 처리해주는 역할을 하는 MemberRepository Interface 구현체 이 역할들을 실제로 구현해낸 구현체 MemberSerivceImpl MemoryMemberRepository 를 구현해 보도록 하자. member 먼저 회원과 관련된 내용만을 모아두기 위해 hello.co.. 이전 1 2 3 4 5 6 다음
