발자국남기기

생성자도 만들어야 하고, 주입 받은 값을 대입하는 코드도 만들어야 하고 필드주입처럼 좀 편리하게 사용하는 방법은 없을까?? 롬복 라이브러리 적용하기 build.gradle에 설정을 추가해준다. 참고로 처음에 spring프로젝트를 만들때 thymleaf처럼 Dependencies에서 Lombok을 선택하여 세팅할 수도 있음. 처음 만들때 추가하지 않았기 때문에 직접 추가시켜줌. (설정에 들어가서 Enable annotation processing 체크) 롬복의 기능 우리가 원래는 필드에 getter / setter를 만드려면 위와 같이 만들어줘야했지만, 롬복을 사용하면 getter / setter 자동으로 생성해준다. @Getter / @Setter 애노테이션 사용 생성자 관련 애노테이션도 제공하고 굉장히..

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

주입할 스프링 빈이 없어도 동작해야 할 때가 있다. 그런데 @Autowired만 사용하면 required 옵션의 default가 true이기 때문에 자동 주입 대상이 없으면 오류가 발생한다. 자동 주입 대상을 옵션으로 처리하는 방법은 다음과 같다. @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 X org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력 Optional : 자동 주입할 대상이 없으면 Optional.empty가 입력 required= false를 통해 noBean1 자체가 호출이 되지 않은 것을 확인할 수 있다.

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

컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까? 1. 자동 빈 등록 vs 자동 빈 등록 (둘다 컴포넌트 스캔) 2. 수동 빈 등록 vs 자동 빈 등록 자동 빈 등록 vs 자동 빈 등록 중복 등록되는 경우 스프링은 오류를 발생시킨다. ConflictingBeanDefinitionException 수동 빈 등록 vs 자동 빈 등록 위는 우리가 @Component 애노테이션을 붙혀 자동으로 빈 등록되는 클래스이다. 이와 똑같은 빈 이름(memoryMemberRepository)을 가진 빈을 수동으로 등록시켜보겠다. 실행시켜보니 충돌이 발생하지 않고 테스트가 성공한 것을 확인할 수 있다. 콘솔로그를 살펴보자. 다른 정의에 의해 오버라이딩되었다는 로그가 있다. 즉, 이러한 경우네는 수동 빈 등록이 우선권..

includeFilters : 컴포넌트 스캔 대상을 추가로 지정 excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정 먼저, 애노테이션을 만들어보자. 클래스 타입에 붙는 애노테이션이라는 의미이다. @MyIncludeComponent가 붙으면 컴포넌트 스캔에 추가 @MyExcludeComponent가 붙으면 컴포넌트 스캔에서 제외 하도록 만들어보려한다. 컴포넌트 대상으로 추가할 BeanA 컴포넌트 대상에서 제외할 BeanB Config설정 클래스에서 Filter를 만들어 Test하기 includeFilters를 사용하여 Filter타입은 ANNOTATION으로, MyIncludeComponent 애노테이션이 붙은 클래스들은 컴포넌트 대상에 추가 excludeFilters를 사용하여 Filte..

탐색할 패키지의 시작 위치 지정 모든 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸린다. 그래서 꼭 필요한 위치부터 스캔하도록 시작 위치를 지정할 수 있다. basePackages를 사용하여 스캔할 범위를 지정한다. 위와 같이 작성하면 member패키지 내에서만 컴포넌트 스캔을 진행하여 memberServiceImpl과 memberMemberRepository만 빈으로 등록된다. 확인해보면 위와 같이 3개만 빈으로 등록된 것을 확인할 수 있다. basePackages = {"hello.core", "hello.service"} 와 같이 여러 시작 위치를 지정할 수도 있다. basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다. basePack..

지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다. 이렇게 등록해야할 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다. 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 또 의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공한다. @ComponentScan 애노테이션은 @component가 붙은 클래스를 모두 스캔하여 스프링 빈으로 등록해준다. @Configuration또한 컴포넌트 스캔의 대상이므로 Filter를 사용하여 제외시켜주었다. 앞서 만든, AppConfig나 TestConfig등 @Configura..

@Configuration 과 Singleton Singleton이 무엇인지 Spring Container를 통해 이를 유지하는 것을 확인해보았다. AppConfig를 다시 보자 스프링이 초기화되어 스프링 컨테이너에 Bean들이 등록될 때를 생각해보자. memberService() -> memberRepository() 호출 이는 new MemoryMemberRepository()를 호출 orderService() -> memberRepository()호출 new MemoryMemberRepository()호출 응?? 이렇게되면 MemoryMemberRepository가 2개가 생성되어 싱글톤이 깨지는 것이 아닌가?? 직접 테스트를 해보자! 먼저, MemberServiceImpl 과 OrderServic..

싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 무상태(stateless)로 설계해야 한다!! (Restful API에 대해 알아볼 때 본 그 stateless!!) 특정 클라이언트에 의존적인 필드가 있으면 안된다. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. 가급적 읽기만 가능해야 한다. 가급적이면 수정을 하면 안된다는 의미 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다. 참고 : docs.oracle.com/en/java/javase/11/..