에드가의 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컨테이너에 생성되어 있는 객체를 응답해주는 것이다.

스프링에서는 DI컨테이너라는 핵심기술이 있다. DI컨테이너는 무엇일까?

DI컨테이너는 @Bean으로 등록한 객체들을 관리해주는 컨테이너 라고 생각해도 좋다.

그렇다면 @Bean 으로 DI컨테이너에 어떻게 등록을 할까?

기존 외부에서 관리해주는 ConfigApp 이라는 클래스에 @Configuration 이라는 어노테이션을 등록을 해준다.

그렇다면 그 클래스안에 있는 메소드들을 @Bean이라는 어노테이션을 작성하여 DI컨테이너에 Bean으로 등록을 할 수 있다.

그렇다면 @Bean 으로 등록을 한 객체들을 어떻게 사용을 하는 것 인가?

위 사진의 에서 주석이 된 코드를 보면은 개발자가 직접 객체를 생성하고 사용을 하는 것을 확인할 수 있다.

하지만 아래 코드에서는 DI컨테이너에 등록된 Bean을 Bean의 이름과 타입을 지정해서 사용하는 것을 볼 수 있다.

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

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

예로 들어 한 식당의 주방장이 요리를 하면서 서빙을 하는 것 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에만 의존을 하고 있기 때문이다. 

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

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

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

◈ Spring Project 생성 ◈

오늘은 스프링부트 프로젝트를 간단하게 생성하는 방법을 알아보도록 합니다.

프로젝트에 사용할 것은 ☞ Spring boot ☞ Gradle IDE은Eclipse를 사용합니다.

방법으로 프로젝트를 생성해보도록 합니다.

start.spring.io/

해당 페이지에서 Artifact은 사용하실 프로젝트 명을 입력하시면 됩니다.

Maven/Gradle 사용유무에 따라 체크박스를 선택하시면 됩니다.

해당 항목을 입력후에 "GENERATE" 를 클릭하시면 study.zip 파일이 다운로드가 되는 것을 확인 할 수있습니다.

사용하실 폴더에 압축을 풀어주시면 해당 프로젝트가 생성된 것을 확인 할 수있습니다.

이제 Eclipse에 생성한 프로젝트를 import 하겠습니다.

import 하는 창에서 Existing Gradle Project를 선택하여 생성한 프로젝트의 경로를 선택합니다.

로그가 찍힌걸 보니 정상적으로 실행되는 것을 확인 할 수 있습니다.

☞ 해당 블로거는 공부/기록용 으로 사용되오니 잘못된 정보나 부족한 정보는 공유해주시면 감사드립니다. ☜

◈ 좋은 객체지향 원칙 5가지 ◈

지금 소개할 것은 SOLID 라는 객체지향 원칙입니다.

이 원칙은 스프링에서 뿐만 아니라 객체지향 개발을 할때 알아두면은 도움이 될 것입니다.

①. SRP (Single Responsibility principle) 단일 책임 원칙

②. OCP (Open / Closed Principle) 개방-폐쇄 원칙

③. LSP (Liskov Substitution Principle) 리스코프 치환 원칙

④. ISP (Intterface Segregation Principle) 인터페이스 분리 원칙

⑤. DIP (Dependency Inversion Principle) 의존관계 역전 원칙

위 5가지에 원칙에 대해서 알아보도록 합니다.

▶ SRP (단일 책임 원칙) 이란? ◀

Single Responsibility Principle 의 약자인 SRP 단일책임 원칙이란 간단하게 말해서 1개의 Class는 하나의 책임만 가지고 있어야 한다.

그럼 여기서 책임이란 무엇을 뜻하는가? 라는것이 생각이 들것이다. 

책임은 그때 상황에 따라 책임이 클수도 있고 작을 수도 유동적일 것이다 그럼 어떠한 기준으로 SRP 원칙 을 잘 지켯다고 말할 수 있을까?

어떠한 작업이 UPDATE가 되엇을 시점에 판단을 할 수가 있다. 예로 들어 A라는 Class 파일을 수정해야 하는 상황이 오면은 그 수정한 A.Class 파일로 인해 다른 Class파일들까지 영향이 미치는 것 이 적으면은 단일 책임 원칙을 잘 수행 한 것이다.

그와 반대로 1개의 Class 파일을 고쳣을뿐인데 여러 파일에서도 문제가 생기면은 단일 책임 원칙을 위반 한것이다.

▶ OCP (개방-폐쇄 원칙) 이란? ◀

개방-폐쇄 원칙에는 다형성을 이용하는 것이다. 확장에는 OPEN 되어 있지만 수정에는 CLOSE 되어 있다 라고 생각하면 좋다. 

확장에는 열려있고 그게 아닌 변경되는 시점에는 닫혀있어야 한다? 이게 무슨 어이없는 말인가 예시로 간단하게 이해를 해보자

나(클라이언트) 는 명품브랜드에 옷을 입고 있다고 생각해보자. 여기서 다른 옷을 입고 싶어질때 다해져있는 품질을 옷입으라고 했을때 어느 누가 명품브랜드를 입다가 싸구려 옷을 입는것을 좋아 하겠는가? 이같은 경우에 다른 옷을 입을려고 하는 행위를 확장 이라고 할 수 있다. 그렇다면 확장 하는데에는 매우 문제가 될 것이다.

그와 반대로 

나(클라이언트) 는 추상적인 옷(Interface) 에만 의존하고 있다고 생각해보자.

그렇다면 나(클라이언트)는 명품옷을 입든 싸구려입을 입든 언제든지 다른 옷으로 대체 가능한 상황이 되는 것이다. 

즉 나(클라이언트) 는 옷(Interface) 라는 것에만 바라보고 있고 옷(Interface)은 다른 옷을 입히고 싶은 것(구현된 클래스) 만 만들면 언제든지 유연하게 확장이 가능한 것이다.

▶ LSP (리스코프 치환 원칙) 이란? ◀

리스코프 치환 원칙은 간단하게 생각해볼 수 있다.

위의 OCP(개방-폐쇄 원칙) 원칙은 Interface를 바라보고 있고 해당 Interface는 특정 기능을 구현된 Class파일들이 있을 것이다.

여기서 LSP(리스코프 치환 원칙)을 잘 지켯을때와 원칙을 위반 했을때의 차이점을 알아보자.

※ LSP(리스코프 치환 원칙)을 잘 시켯을 경우 ※

축구선수 라는 인터페이스가 있다고 생각했을때 발로 공을 차다 라는 기능을 선언하고 구현된 기능 Class파일은 축구공을 차는 기능을 만들었을 것이다.

이경우에는 리스코프 치환 원칙을 잘 짙켯다고 할 수 있다.

※ LSP(리스코프 치환 원칙) 위반 ※

리스코프 치환 원칙을 위반 하는경우는 간단하다. 축구선수 인터페이스에서 발로 축구공을 차는 기능을 선언 후 

구현하는 Class파일에서 축구공을 손으로 던지는 기능을 만들 경우에 리스코프 치환 원칙을 위반 하는 것이다.

해당 목적을대로 기능을 만들어야 한다.

▶ ISP (인터페이스 분리 원칙) 이란? ◀

인터페이스를 분리시킨다는 것이 무엇을 말하는건가? 여기서 객체지향이라는 개념도 생각하면 좋다.

인터페이스란 간단히 말해 기능들의 집합소 라고 생각해보자. 지하철이라는 인터페이스안에는

교통카드 라는것이 있을 수 도 있고 지하철운행 이라는 것도 있을 수도 있고 수없이 많을 것이다.

여기서 인터페이스를 분리를 시켜보자. 교통카드라는 인터페이스는 이에 관련된 요금,벌금 등같은것만

관련된 기능들이 있을 것이고,

지하철 운행이라는 인터페이스는 지하철 운전, 기사관리, 급행, 같은 지하철운행에 관한 수많은 기능들이 있을

것이다. 여기서 이러한 모든 기능들을 1개의 인터페이스에서 관리한다고 했을때 무척 골치가 아플 것이다.

이러한 골치아픔을 피하기 위해 각각의 인터페이스를 분리를 시켜놓으면은 어떠한 수정이 일어낫을때 해당 인터페이스만 수정하면 되니깐 관리하기에 아주 편리 해질 것이다.

▶ DIP (의존관계 역전 원칙) 이란? ◀

위에서 말한 OCP(개방-폐쇄 원칙)을 다시 생각해보자.

간단하게 설명해자면 클라이언트는 인터페이스의 구현객체를 알면 안된다는 뜻이다.

클라이언트는 오로직 인터페이스에만 의존 하도록 잘 설계하여 만들어야 하는 것이다.

☞ 부족한 설명이나 잘못된 부분은 댓글로 언제나 환영입니다. ☜

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

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

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

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

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

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

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

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

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