에드가의 Daily

우리가 개발을 할때 사용하는 JAVA나 Spring @Bean 에 대해서 많이 들어봣을 것이다.

우리가 사용하는 Spring boot 에서는 처음 어플리케이션을 시작을 할때 @Bean 을 컨테이너에 사용하기 좋게 미리 넣어둔다. 

우리는 스프링이 DI컨테이너에 넣어둔 Bean을 꺼내어 사용하는것을 잘 알고 있을 것이다.

그렇다면 Bean은 언제 생성이 되고 언제 소멸이 되는지 궁금해 졋다.

◈ Spring Bean 이벤트 처리 ◈

컨테이너 생성 

              ☞ 빈 생성

                          ☞ 외존관계 주입

                                              ☞ 초기화 콜백

                                                                  ☞ 실제 사용

                                                                                    ☞ 소멸되전 콜백

                                                                                                          ☞ 종료

 여기서 초기화 콜백과 소멸되기 전 콜백은 무엇을 말하는 것일까?

초기화 콜백 : 빈이 생성된 후 의존관계 주입이 일어난다. 의존관계 주입이 끝나면 호출

소멸되기 전 콜백 : 빈이 소멸되기 직전에 호출된다.

간단하게 Bean의 LifeCycle 생명 주기에 대해서 알아보았습니다.

스프링 부트에서 공부를 하다보면은 @ComponentScan 이라는 어노테이션을 본적이 있을 것이다.

@ComponentScan 은 어떤 역할을 해주는가?

특정 어노테이션들을 자동으로 스캔을 해주는 아주 유용한 어노테이션이다.

기본적으로 @ComponentScan 어노테이션이 스캔해주는 대상은 5가지로 나뉠수 있다.

1. @Component
2. @Controller
3. @Service
4. @Repository
5. @Configuration

5가지로 나뉘어 진다. 

그리고 @ConponentScan 은 자기가 위치하고 있는곳부터 스캔을 시작한다.

무슨말이냐면은 프로젝트 파일구조가 

java / com / spring / boot 라고 가정했을때 @ComponentScan 어노테이션을 가지고 있는 파일 현 위치가 com폴더에 존재고 있다고 하면은 com 위치부터 @Componet 가 붙어있는 녀석들을 찾아주는 것이다.

하지만 스프링 부트에서는 @ComponetScan 의 위치를 조절해야 하는 것들은 기본적으로 제공을 해주고 있다.

어떻게 제공을 해주고 있는가?

스프링 부트에서는

스프링 부트를 시작해주는 메인 메소드가 있다. 사진에 보이는 @SpringbootApplication 해당 어노테이션을 들어가 보면은

스프링 부트를 시작해주는 어노테이션에 우리가 알고싶어 하던 @ConponentScan 어노테이션이 정의 되어 있는 것을 확인 할 수 있다. 

그렇다면 당연히 부트를 시작 Run을 하게되면은 우리가 @ComponentScan 으로 하나하나 조절해가야 하는것을 자연스럽게 스프링 부트가 기능을 대신 해주는 것을 확인 할 수 가 있을 것이다.

스프링을 사용하다보면은 @Configuration 과 싱글톤이라는 말을 많이 듣게 될 것이다.

※ 싱글톤은 무엇인가? ※

☞ 우리가 new 연산자로 객체를 생성하는 것은 잘 알고 있을 것이다. 그렇다면 똑같은 객체를 여러번 new 연산자로 

생성을 하게된다면 당연히 생성하는 것마다의 레퍼런스가 다를 것이다. 

여기서 문제점은 똑같은 객체를 100번 1000번 그이상으로 계속 사용할때마다 생성을 하고된다면 당연히 과부하가 걸릴 것이 뻔하다.

그렇다면 이러한 방법을 어떻게 해결할 수 있을까? 

싱글톤을 사용하는 것이다. 처음 최초로 사용할때 1번 객체를 생성하고 그 후 에 사용할때는 최초 생성한 것을 사용하는 것이 싱글톤이다.

아래 그림으로 확인해 보자.

@Configuration
public class ConfigApp {

	@Bean
	public MemberService memberService() {
		return new MemberServiceImpl( memberRepository());
	}

	@Bean
	public OrderService orderService() {
		
		return new OrderServiceImpl(  
				memberRepository(),
			    discountService()
			 );
	}

※ 싱글톤 전 ※

※ 싱글톤 적용 ※

그렇다면 과연 어떻게 처음 생성한 것을 사용할 수 있게 만들어 줄까? 제목에서 언급한 @Configuration 이라는 어노테이션이 DI컨테이너에 생성한 Bean을 관리해준다.

※ @Configuration ※

원리는 이러하다 처음 최초로 생성할때 는 위에 코드에서 우리가 작성한 코드로 객체를 생성한다. 

◈ 주의점 ◈

실제 DI컨테이너에는 우리가 생성한 객체가 들어가는 것이 아니다. CGLIB 이라는 라이브러리를 사용하여 이 라이브러리가 생선한 객체를 DI컨테이너에 주입을 시켜주는 것이다.

그 후에 요청이 오면은 @Configuration DI컨테이너에 생성되어 있는 객체를 응답해주는 것이다.

관심사의 분리란 무엇일까?

말그대로 서로의 관심사를 따로따로 향하도록 분리를 시키는 것이다.

예로 들어 한 식당의 주방장이 요리를 하면서 서빙을 하는 것 VS 주방장은 요리만 서빙은 알바만 하도록 하는 것

코드로 예시로 이해해보자.

1번째 주방장이 요리를 하면서 서빙도 같이 한다는 것을 코드로 하는게 어떤식일까? 

여기서 보면은 해당 A라는 클래스에는 MemberService와 구현클래스인 MemberServiceImpl 을 둘다 의존하고 있다.

이러한 경우에는 DIP(Dependercy Inversion Principle) 을 위반하는 것과 같다고 생각한다.

※ 위같은 경우 문제점은 해당 인터페이스의 다른 로직을 수행해야 할 경우 MemberServiceImpl의 클래스에서 수정이 이루어 져야 한다. 수정이 이루어 지는 순간 OCP (Open / Close Principle) 원칙을 위반 하게 된다. ※

그러하면 DIP원칙,OCP원칙을 지키게 하기위해서는 어떻게 코드를 해야하는 것일까?

위 사진에서는 [ 인터페이스 변수명 = new 구현체; ]  이런식이지만 오로지 인터페이스만 의존하도록 코드를 바꾸면

이렇게 코드를 수정을 하게 된다면? 구현체가 아닌 오로지 Only 인터페이스만 의존하게 되는 것이다.

그렇다면 ConfigApp 이라는 클래스를 만들어서 의존관계 주입 개념을 도입을 하게 되면 더욱 DIP,OCP 원칙을 지키면서 개발을 할 수 있게 된다.

MemberSericeImpl 클래스에는 MemberRepository 라는 인터페이를 의존하고 있다.

그와동시에 MemberRepository 의 구현체는 생성자를 통해서 받아오고 있다.

ConfigApp 이라는 클래스에서 리턴해주는것이 MemberServiceImpl 과 위 사진에서 생성자로 받을 수 있게 해둔 MemberRepository 구현체를 리턴해주는 것이다.

한마디로 MemberServiceImpl 과 MemoryMemberRepository 를 리턴해주는 것이다.

그렇다면 ConfigApp 클래스를 어떻게 사용하여야 하는 것일까?

아래 사진은맨 처음 사진과 같은 메인 클래스 이다.

일단 첫번째로 ConfigApp을 인스턴스화를 해야한다.

아래코드를 보면 처음 코드방식과 조금 다를것이다. 처음사진은 바로 new MemberServiceImpl 을 했엇지만

이 사진은 config.MemberService() 를 사용하였다.

config에서는 2가지 역할이 있다.

1번째 MemberService의 구현체인 Impl을 생성한다.

2번째 생성자로 Impl에서 사용하는 인터페이스도 같이  생성을 하게 되면은 

Impl에서 사용하는 인터페이스에서 기능 추가/ 다른 기능 사용 등등 다양한 이유가 있지만 수정이 일어날 경우 Impl을 고칠 필요가 없다. 

오로지 interface에만 의존을 하고 있기 때문이다. 

그렇다면 메인 메소드에서는 오로지 무엇을 사용할지만 관심을 가지면 될 것이다.

아주 간단하면서도 복잡한 개념인거 같다.

※ 해당 블로그는 공부용/기록용으로 쓰입니다. 간단한 피드백 주시면 감사히 받겠습니다. ※

                                                  ◈ 스프링에 대해 간단하게 알아보자 ◈

스프링이란 첫번째 목표는 개발을 할때 더욱 편리하게 더욱 가속성 있게 개발을 하기위해 만들어 진 것이라고 생각합니다.

과연 어떻게 더욱 편리하게 개발을 지원을 해줄까? 라는 생각이 들겁니다.

스프링은 JAVA를 기반한 프레임 워크라고 해도 무방합니다.

JAVA가 무엇이 좋으냐? 라고 물어보면은 저는 당연하게 "객체지향에 특화되어 있어서요~" 라고 대답을 할 것입니다.

즉 스프링은 JAVA가 가진 "객체지향"을 더욱 극대화시켜주는 프레임 워크입니다.

정리하자면은 스프링은 객체지향을 극대화시켜서 개발을 편하게 지원도와주는 프레임 워크라고 생각합니다.

스프링에 대해 간단하게 알아 보았습니다.

☞ 저의 공부를 위한 용도이므로 더 많은 지식과 잘못된 것이 있으면 댓글로 공유 부탁드립니다.