발자국남기기

1. 인터페이스 InitializingBean, DisposableBean 앞서 만든 NetworkClient 클래스를 InitializingBean과 DisposableBean의 구현체로써 구현해보자. InitializingBean의 구현메서드 afterPropertiesSet은 객체를 생성하고 의존관계 주입이 끝나면 호출되는 메서드이다. DisposableBean의 구현메서드 destroy는 스프링 컨테이너가 close될 때 스프링 빈들이 하나씩 소멸되면서 호출된다. 따라서 안전하게 연결을 종료할 수 있도록 해준다. 이제 테스트를 다시 실행해보자. 객체 생성 후 초기화 메서드(afterPropertiesSet)과 소멸 전 destory메서드를 확인할 수 있다. 하지만 초기화, 소멸 인터페이스에는 단점..

DB Connection pool이나, Network Socket처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.(java와 db연결할 때 conn객체 사용하여 연결 초기화하고 종료하는 작업을 뜻함.) 스프링을 통해 이러한 초기화 작업과 종료 작업을 어떻게 진행하는지 알아보자. 간단하게 외부 Network에 미리 연결하는 객체를 하나 생성한다고 가정. (실제로 네트워크에 연결하는 것이 아니라 단순 문자만 출력하도록) 테스트 코드 여기서는 컨테이너를 종료(close)하기 위해 상위 클래스인 ConfigurableApplicationContext를 사용했다. 이제 테스트를 돌려보면 url에 nu..

편리한 자동 기능을 기본으로 사용하자! 그러면 어떤 경우에 컴포넌트 스캔과 자동 주입을 사용하고, 어떤 경우에 설정 정보(AppConfig)를 통해서 수동으로 빈을 등록하고 의존관계를 수동으로 주입해야 할까? 결론부터 얘기하면, 스프링이 나오고 시간이 갈 수록 점점 자동을 선호하는 추세이다. 스프링은 @Component 뿐만 아니라 @Controller, @Service, @Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 추가로 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계했다. 설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누..

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

@Qualifier("mainDiscountPolicy") 이렇게 코드를 작성하면 컴파일시 타입 체크가 안된다. 컴파일 중에 오류를 잡을 수가 없다는 의미이다.("mainnDiscountPolicy"라고 오타를 내도 컴파일은 되고 그 이후에 Exception이 발생한다.) 이를 애노테이션을 만들어서 해결해보자. 위와 같이 "mainDiscountPolicy"를 Qualifier로 가지는 애노테이션을 생성하였다. 이제 우리는 @MainDiscountPolicy를 가져다가 사용하면 되는 것이다. 위와같이 오타를 발생하면 컴파일 전에 오류를 잡아낼 수 있어진다. 이제 OrderServiceImpl의 생성자 주입에 우리가 만든 애노테이션을 넣어주면 스프링이 어떤 타입의 할인정책을 사용해야하는지 알게되는 것이다...

@Autowired는 타입으로 조회한다. 타입으로 조회하게 되면 선택된 빈이 2개 이상일 때 문제가 발생한다. DiscountPolicy의 구체인 FixDiscountPolicy와 RateDiscountPolicy 둘 다 스프링 빈으로 등록시키고 DiscountPolicy타입으로 조회를 하면 Exception이 발생한다. 하위 타입으로 지정할 수도 있지만, 하위 타입으로 지정하는 것은 DIP를 위배하고 유연성이 떨어진다. 그리고 이름만 다르고, 완전히 똑같은 타입의 스프링 빈이 2개 있을 때 해결이 안된다. @Autowired 필드 명 매칭 @Autowired는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름 / 파라미터 이름으로 빈 이름을 추가 매칭한다. 위와 같이 파라미터이름을 보고 같은 타..

생성자도 만들어야 하고, 주입 받은 값을 대입하는 코드도 만들어야 하고 필드주입처럼 좀 편리하게 사용하는 방법은 없을까?? 롬복 라이브러리 적용하기 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라 불리는 필드의 값을..