발자국남기기

Singleton pattern을 정보처리기사 시험을 준비하며 디자인 패턴의 생성패턴 중 하나로 알고 있었는데 이것은 객체 인스턴스가 오직 1개만 생성되야하는 경우에 사용하는 패턴이다. 예를 들어, 설정 파일같은 경우에는 객체가 여러 개 생성되면 설정 값이 변경될 위험이 생기므로 싱글톤을 사용해야한다. 싱글톤을 이용하게 되면 하나의 인스턴스를 메모리에 등록해서 여러 스레드가 동시에 해당 인스턴스를 공유하여 사용하게끔 할 수 있으므로, 요청이 많은 곳에서 사용하면 효율성이 높아지는 장점이 있다. (하지만 동시성 문제 고려해야함) 웹 애플리케이션과 싱글톤 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 하게 된다. 요청이 들어오면 AppConfig는 직접 객체를 만들어 반환시켜준다. 클라이언트 B(다른고객..

앞서 스프링이 다양한 설정 형석을 지원하는 것을 확인해보았다. 어떻게 지원하는 것일까? 그 중심에는 BeanDefinition이 있다. 이것은 역할과 구현을 개념적으로 나눈 것이다 XML을 읽어서 BeanDefinition을 만든다. Java 코드를 읽어서 BeanDefinition을 만든다. 즉, 스프링 컨테이너는 어떤 코드인지를 아는 것이 아니라, BeanDefinition을 알고 있는 것이다. "BeanDefinition"을 빈 설정 메타정보라 한다. Java의 '@Bean' / XML의 각각 하나씩 메타 정보가 생성된다. 스프링 컨테이너는 이 메타정보를 기반으로 Bean을 생성한다. 즉, 스프링 컨테이너는 BeanDefinition에만 의존한다. AnnotationConfigApplicationC..

스프링 컨테이너는 다양한 형식의 설정 정보를 받아드릴 수 있게 유연하게 설계되어 있다. java XML Groovy 등등 임의로 구현하여 새로운 설정 정보 형식을 사용할 수 있음 XML 설정 사용해보기 최근에는 Spring Boot를 많이 사용하면서 XML기반의 설정은 잘 사용하지 않는다. 하지만 아직 많은 레거시 프로젝트들이 XML로 되어있고, XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점도 있으므로 알아두어서 나쁠 것은 없다. GenericXmlApplicationContext를 사용하여 xml 설정 파일을 넘기면 된다. 테스트 코드 XML 설정 파일 일반적으로 java코드를 제외한 나머지 파일들은 resources 폴더 내부에 놓는다. Spring Config로 작성할 XML문..

BeanFactory❓❓ ApplicationContext❓❓ BeanFactory 스프링 컨테이너의 최상위 인터페이스 스프링 빈을 관리하고 조회하는 역할 담당 getBean()을 제공 앞서 Bean을 조회하고 꺼내는 등의 대부분 기능은 BeanFactory가 제공하는 기능 ApplicationContext BeanFactory기능을 모두 상속받아 제공한다. 빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데 그럼 둘의 차이는 무엇일까? 애플리케이션을 개발할 때 빈은 관리 / 조회 기능과 더불어 수 많은 부가 기능이 필요 그 부가 기능을 제공 실제로 ApplicationContext에 들어가보면 여러가지를 상속받고 있고 최상위에 BeanFactory가 있음을 확인할 수 있다. 🙀Applic..

기본 스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법 ac.getBean(빈이름, 타입) ac.getBean(타입) 조회 대상 스프링 빈이 없으면 예외 발생 NosuchBeanDefinitionException : No bean named "빈이름" available 1. 빈 이름으로 조회!! Assertions로 검증 memberService가 어떤 객체 인스턴스인지?(isInstanceOf) MemberServiceImpl의 인스턴스라면 테스트 통과 테스트 성공 2. 이름 없이 타입으로만 조회 테스트 성공! 하지만 같은 타입이 여러 개일 경우에는 곤란해질 수 있음. 3. 구체 타입으로 조회 테스트 성공! 스프링 컨테이너에 구현체가 등록만 되어있으면 조회가 됨 스프링 빈에 등록되어 있는 ..

스프링 컨테이너에서 실제 스프링 빈들이 잘 등록 되었는지 확인해보자. Junit 테스트 코드로 작성 1. 모든 빈 출력 Bean명과 담겨있는 객체들을 출력하였다. 위의 org.springFramework ~~ 들은 스프링이 내부적으로 스프링 자체를 확장하기 위해 쓰는 Bean들이다. ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름을 조회 ac.getBean() : 빈 이름으로 빈 객체(인스턴스)를 조회 2. 애플리케이션 빈 출력 getBeanDefinition : Bean에 대한 메타데이터 정보 getRole() : Bean의 역할을 가져오는 메소드 getRole이 ROLE_APPLICATION이라는 뜻은 스프링이 내부적으로 등록한 Bean이 아니라 우리가 Applic..

스프링 컨테이너😙 ApplicationContext 를 스프링 컨테이너라 한다. ApplicationContext 는 인터페이스이다. 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. 직전에 AppConfig 를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것 이다. 자바 설정 클래스를 기반으로 스프링 컨테이너( ApplicationContext )를 만들어보자. new AnnotationConfigApplicationContext(AppConfig.class); 이 클래스는 ApplicationContext 인터페이스의 구현체이다. > 참고: 더 정확히는 스프링 컨테이너를 부를 때 BeanFactory , Appli..

스프링 형식으로 AppConfig 변경 @Configuration : 설정 정보, 애플리케이션의 구성 정보를 담당한다는 뜻의 애노테이션 @Bean : 스프링 빈으로 등록 MemberApp 클래스 ApplicationContext ==> 스프링 컨테이너라고 보면 된다. 앞서 등록한 Bean들을 모두 관리해주는 역할 Parameter로 우리가 만든 AppConfig을 넣어주면 AppConfig의 환경설정 정보를 가지고 객체를 생성하고(@Bean) 스프링 컨테이너에 모두 집어넣은 후 관리해준다. getBean에는 이름과 반환 타입을 적어줘야함. 어떤 Bean을 꺼낼 것인지(메서드 이름) 실행시켜보자! 정상 작동하는 것을 확인할 수 있다. 자세히 살펴보면 appConfig, memberService, membe..

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

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