🌊 ._.sori🪽

[ @Controller와 @RestController ]

[ Hello,World 출력하기 ]

Controller 안에
@GetMapping( )이라는 존재였다.

과연 @GetMapping은 어떤 역할을 하는 것일까?

데이터에는 두가지 전송방식이 존재한다.

GET

• URL(주소)에 데이터를 포함시켜 보낸다.
• 데이터는 헤더에 포함되어있다.
• URL에 데이터가 노출되어 보안에 취약하다.
• 캐싱(데이터를 가까운 곳에 임시로 저장한 후, 빠르게 불러오는 프로세스)할 수 있다.
• 주로 조회, 검색할 때 사용한다.

POST

• URL(주소)에 데이터를 포함시키지 않는다.
• 데이터를 바디에 포함한다.
• URL에 데이터가 노출되어있지 않아 GET방식 보단 보안이 높다.
• 캐싱((데이터를 가까운 곳에 임시로 저장한 후, 빠르게 불러오는 프로세스)할 수 없다.
• 주로 데이터를 서버에 저장, 수정할 때 사용한다.

@GetMapping( )

• Get 요청을 하는 API 어노테이션이다.
• 경로 매핑에 따라 어떤 페이지를 보여줄지 결정한다.
  (매핑, 여러 요소를 연결하는 과정 혹은 결과물을 말한다. 예시를 들어보면, 강남 맛집을 검색했을시 강남에 있는 모든 식당이 검색되는 경우라고 볼 수 있을 것 같다. 매칭은 키 = 180cm 일대일로 맞는 경우)
• 데이터를 가져올 때 사용한다.
• 반환값은 하나지만 경로는 다중으로 설정 가능하다. 

코드를 보고 이해해보자.

해당 코드는 페이지 반환은 아니고 @RestController(직렬화를 통해 문자열이 페이지에 보이게 해주는)를 사용하여 문자열을 반환하는 코드의 일부이다.

Controller 내부 코드

@GetMapping("")
    public String helloWorld() {
        return "Hello, World";
	}

1. @GetMapping("")으로 ("")에 경로가 적혀있지 않아 루트를(메인 페이지) 의미한다.
2. @GetMapping("") = 사용자가 메인 페이지에 들어가면
3. "Hello, World"를 반환해라. (@RestController를 이용하여)

그러면 이번엔 페이지 반환하는 코드 일부를 살펴보자.

Controller 내부 코드

@GetMapping("")
public String homePage() {
    return "First";
}

1. page라는 이름으로 .html 혹은 .jsp가 있다고 가정하자.
2. 루트 경로("")로 들어간다면
3. First라는 페이지를 반환하라는 명령이 DispatcherServlet에게 전달된다.
4. DispatcherServlet은 ViewResolver로 전달하고
5. ViewResolver가 First라는 이름을 가진 페이지를 찾아 최종적으로 화면에 출력되도록 한다.

@RequestMapping

• 다양한 속성을 지정가능하다.
• value, method, params, headers, consumes, produces의 속성을 가지고 있다.
• 그 속성을 이용하여 Get, Post 등 다양한 동작을 구현할 수 있다.
• 속성이 하나라도 달라야 올바르게 Handler가 매핑할 수 있다.
• 쉽게 생각하면 @RequestMapping에서 조회하는 목적에 맞게 편리하도록 만들어낸 버전을 @GetMapping 등.. 이라고 생각하면 된다.

이것도 쉽게 코드로 살펴보자.

@RequestMapping(value = "", method = RequestMethod.GET)
public String helloWorld() {
    return "Hello,Wrold!";
}

=

@GetMapping("")
    public String helloWorld() {
        return "Hello, World";
    }

@RequestMapping은 method에 .GET으로 어떤 방식으로 사용할건지 명시하고 있다. 

더 자세한 건 나중에 작성하겠다.

목적에 따라 다른 어노테이션

• @PostMapping =  데이터를 게시할 때 사용한다. (Post의 특징을 그대로 가져온 것)
• @PutMapping = 수정할 때 사용하며, 데이터 전체를 갱신하다.
• @DeleteMapping = 데이터를 삭제할 때 사용한다.
• @PatchMapping = 수정할 때 사용하며, 수정된 부분만 갱신한다.

@GetMapping을 포함하여 위의 어노테이션들은 @RequestMapping에서 목적에 맞게 더 편리한 코드를 만든 것이라 생각하면 된다. @RequestMapping에서 다양한 속성을 조합해 원하는 작동방식을 만들어야했다면, 위의 어노테이션은 속성의 조합에 대한 부담을 줄여준 것으로 보인다.

@GetMapping에 대해 알아봤습니다.

그냥 한 줄로 정리하면 들어오는 경로에 맞춰 반환될 페이지를 골라주는 역할인 것 같네요.
@RequestMapping에 대해서는 다음에 정리해볼까 합니다.

아래에 출처를 남겨두겠습니다.
블로그엔 제가 최대한 이해한 내용까지만 적는거라
출처에 들어가시면 더 많은 내용이 있어 공부하시는데 도움되실겁니다.

🪽

틀린 내용이 있다면 댓글로 알려주세요

- @GetMapping의 개념

- Get과 Post

- @RequestMapping 동작방식

- @RequestMapping 옵션

- 매핑과 매칭

[ SpringMVC에 대하여 ]

[ Hello World 출력하기 ]

Hello, World를 출력했다.
그런데 @Controller가 아닌 @RestController를 사용하였다.

왜 @RestController를 사용한걸까?

@Controller

• @Controller는 주로 view를 반환한다.
• ViewResolver를 통해 view를 반환한다.
• AnnotationMethodHandlerAdapter 핸들러 어댑터가 사용한다.
• 메소드 단위로 설정할 수 있기 때문에 효율이 좋다.
• @Controller는 200 OK(성공을 알리는 상태 코드)를 기본적으로 보낸다.

@RestController

• @Controller에 @ResponseBody가 추가되었다.
• Controller를 통해 Json 형태로 반환해야하는 경우 사용한다.
• HttpMessageConverter를 통해 Json 형태로 반환한다.
• 반환되는 객체는 Json으로 Serialize(직렬화)되어 반환된다.
• @RestController는 200 OK(성공을 알리는 상태 코드)를 기본적으로 보낸다.

결론적으로 @Controller는 View를 반환할 때 사용하고, @RestController는 Hello, World 같은 어떤 Json 형태의 데이터를 반환할 때 사용한다는 걸 알았다.

그렇다면 왜 @RestController는 Json 반환이 되는걸까?

직렬화

• 컴퓨터 과학의 데이터 스토리지 문맥에서 데이터 구조나 오브젝트 상태를 동일하거나 다른 컴퓨터 환경에 저장하고 나중에 재구성할 수 있는 포맷으로 변환하는 과정이다.
• 자바 시스템 내부에서 사용되는 객체 또는 데이터를 외부의 자바 시스템에서도 사용할 수 있도록 바이트(byte) 형태로 데이터 변환하는 기술과 바이트로 변환된 데이터를 다시 객체로 변환하는 기술(역직렬화)을 아울러서 이야기한다.

직렬화를 쉽게 이해해보자면, 시스템 내부에서 처리하기 편리한 어떤 데이터 형태로 존재하다가 우리에게 보여줄 때 우리가 이해할 수 있는 모습으로 형태를 변화시키는 것을 뜻하는 것 같다.

Q. @Controller는 Json 형태로 반환을 못하나?

A. 그건 아니다. 할 수 있다. @ResponseBody를 붙여주면 Json 형태로 반환이 가능하다. 본래 @Controller는 ViewResolver가 작동하여 view를 반환할 수 있도록 해준다. 하지만 @ResponseBody를 붙이면 @RestController처럼 HttpMessageConverter가 개입하게 되어 객체를 직렬화하여 전달하게 된다. 또한 MessageConverter에는 데이터의 종류(단순 문자열인지, 객체인지...)에 따라 서로 다른MessageConverter가 작동하게 된다.

// @ResponseBody를 붙인 코드
@Controller
public class HelloController {

    @GetMapping("")
    @ResponseBody
    public String helloWorld() {
        return "Hello, World";
    }

}

<결과>

👍

Http 상태 코드

• 특정 HTTP 요청이 성공적으로 완료되었는지 알려준다.
• 가장 기본적인 성공응답은 200 OK가 있다.

- 더 다양한 상태 코드

Q. @RestController의 기본적으로 반환되는 성공 상태 코드는 200 OK다. 그런데 다른 상태 코드로 바꾸려면 어떻게 해야하나?

A. ResponseEntity를 사용하여 상태 코드를 직접 설정할 수 있다. 

1) ResponseEntity.ok()를 사용한 코드 (200 OK)

// 예제 출처 - mangkyu.tistory (망나니 개발자님)

  @GetMapping(value = "/users")
    public ResponseEntity<User> findUserWithResponseEntity(@RequestParam String userName){
        return ResponseEntity.ok(userService.findUser(userName));
    }

2) ResponseEntity.status(HttpStatus.CREATED)를 사용한 코드 (201 Created)

@GetMapping(value = "/users")
public ResponseEntity<User> findUserWithCreatedResponse(@RequestParam String userName){
    return ResponseEntity.status(HttpStatus.CREATED).body(userService.findUser(userName));
}

코드 설명 :

1. @GetMapping ▻ users 경로로 들어온 요청을 해결하고 응답을 반환한다.
2. ResponseEntity<User> ▻ User(User 안에 있을 어떤 정보들, 이름+나이+주소와 같은...) 객체를 반환하는데, 상태 코드와 함께 반환하다는 뜻. (ResponseEntity로 감싸서 반환)
3. @RequestParam  ▻ 파라미터 이름으로 바인딩(구체적인 값을 할당하는 과정, 이름 = 미나 + 나이 = 10세 + 주소 = 서울특별시와 같은...) 그런데 userName이 옆에 붙었다. 이 의미는 구체적인 값으로 userName이 들어오면(쿼리 파라미터) userName 변수에 저장하겠다는 것이다. (미나라는 값이 url로부터 받아오면 그 값을 userName에 저장하고 데이터베이스에 그 사용자에 대한 다른 정보를 추가적으로 넣을 수 있게 만든다는 의미인 것 같다.)
4. ResponseEntity.status  ▻ 응답상태 코드를 설정하도록 한다.
5. HttpStatus.CREATED  ▻ 201 Created를 의미한다. 요청이 성공적으로 처리되었으며, 자원이 생성되었음을 나타내는 성공 상태 응답 코드이다. 
6. findUser(userName)  ▻ userName을 찾아서 User 객체를 반환하라는 것이다.

결론 : users로 들어온 요청을 해결한 후 성공적이면 201 CREATED를 반환하며 반활할 때 User 내용도 같이 담아서 반환해라. 

Q. 그렇다면 @Controller는 상태 코드를 어떻게 변환할 수 있는가?

A. @RestController와 같이 ResponseEntity.status를 이용하는 방법도 있지만, HttpServletResponse 객체를 이용하여 상태 코드를 설정할 수 있다. 아래 코드를 보면  HttpServletResponse response와 response.setStatus(HttpStatus.CREATED.value()); 코드를 통해 201 CREATED로 상태를 설정하는 걸 볼 수 있다.

    @GetMapping("/users")
    public String findUser(@RequestParam String userName, HttpServletResponse response) {        
        response.setStatus(HttpStatus.CREATED.value());
    }

이번에는 @Controller와 @RestController에 대해 알아봤습니다.

생각보다 정리하는데 오래걸려서 조금 당황스러웠네요...

다 처음보는 내용들이라 하나의 개념을 이해하려면 다른 개념들도 이해해야했고
상태 코드에 대한 부분도 몰랐다가 얼떨결에 간단히 배우고 넘어가게 되는 시간이었습니다.

아래에 출처를 남겨두겠습니다.
블로그엔 제가 최대한 이해한 내용까지만 적는거라
출처에 들어가시면 더 많은 내용이 있어 공부하시는데 도움되실겁니다.

🪽

틀린 내용이 있다면 댓글로 알려주세요

- @Controller와 @RestController의 원리와 차이 그리고 상태코드

- 다양한 Controller에 대해서

- 직렬화에 대해서

- @RequestParam에 대해서

- HttpservletResponse에 대해서

- 다양한 상태 코드

- 스프링사전

- @ResponseStatus에 대하여

처음엔 대충 프로젝트를 시작해보려했지만,
이럴수가! 아는 것이 미약하니 시작할 수 없었다.

그래서 가장 기초적으로 알아야하는 개념을 차근차근 정리해볼까 한다.

두둥, Spring MVC란?

아마 정보처리기사를 준비하거나, IT관련 전공자라면 한 번은 들어봤을 MVC.
이번 기회에 자세히 알아보자.

🪽

"틀린 내용이 있을 수 있습니다."

[ Hello World를 출력하기 ]

1. MVC

• Model - View - Controller로 구성되어있다.
• Model, View, Controller는 독립적으로 움직인다. (각자 맡은 분야만 해결한다)
• MVC 사용시, 결합도를 낮출 수 있다.
• MVC 사용시, 중복코드 제거가 쉽고 유지보수에 좋다.
• MVC 사용시, 확장성과 유연성이 증가한다.

(1)  View

• 사용자가 보는 화면이라고 생각하면 된다.
• 예시를 들어보자, 사용자가 웹 검색창에 [apple]이라고 검색하길 요청했다.

(2)  Controller

• View와 Model을 연결해주는 중간에서 상호작용 역할을 해준다.
• 사용자의 요청을 Controller가 받았다. (DispatcherServlet라는 Front Controller가 받음)
• Controller는 이 요청을 처리하기 위해 [apple]이란 단어를 가지고 있을 Model에게 전달한다.

(3)  Model

• 데이터와 비즈니스 로직을 담당한다. 
• 이때 클라이언트에게 응답으로 돌려주는 작업의 처리 결과 데이터를 Model이라 한다.
• Controller에게 온 요청을 잘 받았다.
• Model은 [apple]이란 단어 관련 데이터를 찾아 Controller에게 다시 전달한다.
• Controller는 받은 정보를 다시 View에게 보내고 View는 사용자에게 결과를 보여준다.

2. Spring MVC 구성요소와 순서

1번

• 사용자에게 요청(Requeest)이 들어왔다.
• 요청은 특정 URL과 함께 들어오게 되는데 GET, POST 등 HTTP 메서드가 함께 전달된다.

2번•3번

• 요청이 들어오면 Front Controller인 DispatcherServlet이 요청을 받게 된다.
• DispatcherServlet은 적절하게 처리할 Controller를 찾기 위해 HandlerMapping을 이용한다.
• 그렇게 HandlerMapping은 들어온 요청 경로와 HTTP 메서드에 따라 적절한 Controller를 정해 반환한다.

4번•5번

• HadlerMapping이 찾은 Controller는 요청을 실제로 처리하는 역할을 한다.
• Controller는 비즈니스 로직(예시로 회원가입을 처리하거나 쇼핑몰에서 결제를 처리하는 것)을 실행하고 그에 필요한 데이터 생성 혹은 DB에서 데이터를 불러온다.
• 쉽게 말해 View로 전달할 데이터를 준비하는 것이고, Model And View가 결과에 담겨 DispatcherServlet에 반환한다.

6번•7번

• 반환된 정보를 기준으로 클라이언트에게 적절하게 보여줄 View를 고를 것이다.
• View Resolver는 Controller가 반환한 View 이름을 기반으로 실제 View 파일을 전달한다.

8번

• View에서 View Rendering이 일어난다.
• View Rendering은 프레젠테이션 로직을 포함하고 있다.
• 프레젠테이션 로직을 통해 데이터를 기반으로 웹페이지를 생성하고 사용자에게 보여준다.

10번

• View에서 Rendering된 결과는 DispatcherServlet에 반환된다.
• 사용자는 자신이 요청한 결과를 받게된다.

3. Spring MVC 를 사용하는 이유

(1) DispathcerServlet

• 기본적으로 다른 MVC는 DispatcherServlet가 없다.
• 그렇기에 Controller가 요청을 받고, 직접처리도 한다.
• DispatcherServlet이 있기엔 요청 처리를 더 간결하게 처리할 수 있도록 해준다.

(2) @로 시작하는 어노테이션의 유무

• 어노테이션의 사용으로 인해 중복적으로 사용되는 코드를(혹은 비슷한 코드) 줄일 수 있다.
•  그로인해 가독성이 향상된다.

(3) Ioc(제어의 역전)와 DI(의존성주입)

• 객체간의 의존성을 프레임워크가 자동으로 주입하고 관리한다.

4. SpringMVC는 어떤식으로 구성을 해야하는가?

쇼핑몰에서 주문을 처리하는 것을 간략하게 예로 들어보자.

(1) Controller

주문이 들어왔을 때 주문 요청을 처리할 Controller를 만들어야한다.

@RestController  혹은 Controller
@RequestMapping("/요청이 들어온 경로")
public class OrderController {

 주문 요청을 직접 처리하지 않고, 해당하는 서비스 계층으로 넘긴다.

 주문 처리 성공시 어떻게 반환할지
 상태 코드와 데이터를 함께 보내는 등...

}

(2) Service

주문 요청을 받아 주문 객체를 생성하는 비즈니스 로직을 만들어야한다.

@Service
public class OrderServiceImpl implements OrderService {

 주문내역을 직접 처리

 예시로, 주문이 들어온 상품이 존재하는지 확인하거나
 생성된 주문을 데이터 베이스에 저장하거나 등...
 결과를 누구에게 반환할지까지 정하는 곳

}

(3) Repository

주문 내역을  저장할 저장소

public interface OrderRepository <Order, Long> {

 Order과 연결된 저장소로 작업 수행

}

(4) Entity

주문 데이터 모델로 주문이 들어오면 객체를 초기화

@Entity
public class Order {

 주문 고유의 ID를 만들거나
 여러개의 주문을 하나의 상품으로 연결되도록 하거나
 생성자를 이용하여 주문을 초기화해주는 것 등...
   
}

(5) DTO
요청과 응답만 연결하는 데이터 구조만 담당, 데이터 전달 객체

public class OrderRequest {

 주문에 필요한 데이터를 받는 객체
 상품 ID, 수량...

}

public class OrderResponse {

 주문 완료한 데이터 반환 객체
 주문 ID, 총 가격...

}

사실 스프링의 패턴에는 MVC만 있는 것은 아니다. 더 다양한 디자인 패턴이 존재하지만, 모델 - 뷰 - 컨트롤러로 용도를 나누고 서로의 역할엔 침범하지 않는 것이 큰 장점이 되어 MVC를 많이 사용하는 것 같다.

공부하면서 이해가 안되는 내용이 많았다.

이해한 내용까지만 블로그에 적어보았다.

아래 적어둔 출처에 들어가 한 번씩 읽어본다면 더 좋을 것 같다.

- spring 출처

- Spring MVC 출처

- Spring MVC의 장점 출처

- Spring MVC 출처

- Spring MVC 출처

- Mapping 출처

8월 전에 다 끝내기로 한 계획,,,! 강의는 모두 들었지만 왜인지 블로그 작성은 미뤄졌다. 그래도 영상 다 들은게 어디냐며 약간의 위로와 함께 블로그 작성을 해보려한다. 코로나로 인해 체력이 박살난건지, 그냥 이미 박살난걸 내가 몰랐던 건지 알 수 없지만 위경련 터지며 길바닥에 주저앉는 인생이어도 오늘도 화이팅!! 모두들 화이팅!

🧸 

🧸 구조파악 레츠꼬우- 🧸

 • scope

ㄴ class :  SingletonTest, SingletonWithPrototypeTest1, PrototypeTest

 • web

ㄴ class :  LogDemoController, LogDemoService

• common

ㄴ class :  MyLogger

Q. 빈 스코프란?

A. 빈이 사용되어지는 범위이다.

✔️  SingletonTest

►  결과

지금까지 우리가 배운 것은 싱글톤 빈 스코프다. 싱글톤 빈 스코프는 싱글톤 빈이 시작되어 끝날때까지 유지된다. 또 같은 요청에 대해 같은 인스턴스 빈으로 반환한다.

✔️  PrototypeTest

@Scope("prototype")
static class PrototypeBean {

}

@Scope("prototype")

: 빈의 스코프를 프로토타입으로 설정한다. 

►  결과

프로토타입 빈의 인스턴스가 다르게 요청된 것을 볼 수 있다. 싱글톤 빈 스코프는 처음부터 끝까지 유지되지만 프로토타입은 의존관계 주입과 초기화(Prototype.init 2번 요청된 것을 보면)까지만 관여한다. 그렇기에 Predestroy 메서드는 실행되지 않는다. (현재 실행 결과에서 Prototype.destroy가 있지만, 따로 코드에 prototypeBean1.destroy();를 적어서 그런것이다.)

✔️  SingletonWithPrototypeTest1

►  프로토타입과 싱글톤을 함께 쓸 경우 생기는 문제점

    @Scope("singleton")
    static class ClientBean {

	private final PrototypeBean prototypeBean;
        
        @Autowired
        public ClientBean(PrototypeBean prototypeBean) {
        	this.prototypeBean = prototypeBean;
        }

        public int logic() {
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        }
    }

코드를 살펴보면 싱글톤 클래스인 ClientBean 내부에 프로토타입 빈이 선언되었다. 모두가 알다시피 싱글톤 빈은 생성시점 딱 한 번 생성되고 그 생성된 것을 중복하여 사용하는 방식이다.(이미 할당된 인스턴스를 같은 빈을 사용할 때 마다 같은 인스턴스 할당) 그러니 그 내부에 함께하는 프로토타입도 본래의 특성이 아닌 싱글톤 빈을 따라가게 되는 것이다.

Q. 만약 같은 인스턴스가 계속 호출되는 프로토타입은 더이상 프로토타입이 아니고 싱글톤이라고 할 수 있나?

A. 맞다. 그 특성이 싱글톤이 되었으니, 더이상 프로토타입이 아니다.

►  주입 시점 차이

static class ClientBean {
 
         @Autowired
         private ApplicationContext ac;
         
         public int logic() {
             PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
             prototypeBean.addCount();
             int count = prototypeBean.getCount();
             return count;
	}
}

전 코드는 싱글톤 빈 내부에 프로토타입이 선언되었다. 현재 코드는 ApplicationContext를 이용해 프로토타입 빈을 따로 관리하고 있음을 알 수 있다. logic 메서드가 호출되면 ac(ApplicationContext)를 통해 프로토타입 빈을 매번 요청하게 된다. 

►  ObjectFactory

static class ClientBean {

	@Autowired
	private ObjectProvider<PrototypeBean> prototypeBeanProvider;
 
	public int logic() {
		PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
		prototypeBean.addCount();
		int count = prototypeBean.getCount();
		return count;
	}
}

ObjectProbvider

: 지정한 빈을 찾아 컨테이너에서 대신 찾아주는 DL 서비스를 제공한다. / 스프링에 의존적이다.

- ObjectProvider 출처

- ObjectFactory 출처

►  JSR-330 Provider

static class ClientBean {

    @Autowired
    private Provider<PrototypeBean> prototypeBeanProvider;

    public int logic() {
        PrototypeBean prototypeBean = prototypeBeanProvider.get();
        prototypeBean.addCount();
        int count = prototypeBean.getCount();
        return count;
    }
}

Provider< >

:  < > 안의 인스턴스를 제공하고 지연, 옵션, 의존적인 경우인 순환참조문제에 쓴다.

- Provider 출처

✔️  MyLogger

가짜 프록시를 이용하여 로그 요청을 위한 클래스

@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {

value

: 웹 스코프의 종류를 의미하며, 현재는 Http 요청 하나가 들어가고 나갈때 가지 유지되는 request로 되어있다.

ProxyMode

: GoF 다자인 패턴으로 해당 객체의 생성이나 초기화를 지연하거나, 접근을 제어할 때, 성능 최적화가 필요한 경우 사용한다.

ScopedProxyMode의 종류

- DEFAULT : 프록싱 없음
- NO : 프록싱 없음 (DEFAULT와 같음)
- INTERFACE : 인터페이스 기반으로 동적 프록싱 생성
- TARGET_CLASS : 대상 클래스 기반으로 CGLIB 프록시 생성
- SCOPED_PROXY INTERFACES : INTERFACE 혹은 TARGET_CLASS 중 하나를 나타내는 특별한 단축형 값이다.

고객이 서비스를 언제 요청할지 모른다. 거기다 

- ProxyMode  출처

••• 이어서 다른 코드 부분 •••

public void setRequestURL(String requestURL) {
    this.requestURL = requestURL;
}

public void log(String message) {
    System.out.println("[" + uuid + "]" + "[" + requestURL + "]" + message);
}

@PostConstruct
public void init() {
    uuid = UUID.randomUUID().toString();
    System.out.println("[" + uuid + "] request scope bean create:" + this);
}

setter를 통해 requestURL을 받는다. 그리고 처음 Http 요청이 오면 @PostConstruct를 통해 uuid를 random으로 만들어 log로 보낸다.

Q. requestURL은 빈이 생성되는 시점을 알 수 없기 때문에 setter로 받는데 왜 생성시점을 모를까?

A. 현재 MyLogger의 코드를 살펴보면, requestURL을 생성하는 코드는 존재하지 않는다. 즉, 다른 클래스에서 받아온다는 것이다. 거기다 MyLogger은 request 스코프로 정의되어있다. 그렇다는건 Http의 요청이 들어오면 새로운 인스턴스가 생성되고, 그 후에 requestURL 값이 결정된다는 것이다. 이러한 이유로 requestURL 빈은 생성시점은 알 수 없다. 일단 요청이 있어야하는데 요청이 언제 올지 모르며 다른 클래스(서비스나 컨트롤러)에 requestURL을 생성하는 코드가 있기 때문이다.

✔️  LogDemoController

로거가 잘 작동되는지 테스트용 컨트롤러

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    private final MyLogger myLogger;

@ReqiredArgsConstructor (Lombok)

: 초기화 되지않은 final 필드나, @NonNull이 붙은 필드에 대해 생성자를 생성하며, @Autowired를 사용하지 않고 의존성을 주입한다.

LogDemoService와 MyLogger 의존관계를 주입해준다. private와 final로 선언한 이유는 읽거나 수정을 못하게 하기 위함이다. 외부에서 수정될 경우 코드에 문제가 생길 수 있기 때문이다.

- @ReqiredArgsConstructor 출처

••• 이어서 다른 코드 부분 •••

@RequestMapping("log-demo")
@ResponseBody
public String longDemo(HttpServletRequest request) {
    String requestURL = request.getRequestURI().toString();
    myLogger.setRequestURL(requestURL);

@RequestMapping( )

: 들어온 요청을 특정 메서드와 매핑하기 위해 사용한다.

현재 코드에서는 @RequestMapping에 대해 괄호 안에 어떤 value값이나 method값을 작성하지 않았다. 그렇다는건 요청방식에 관계없이 url이 일치하는 요청을 처리한다. 그러면 ("log-demo")라고 적혀있으니, log-demo 경로로 들어온 Http 요청을 이 메서드가 처리한다는 의미가 된다.

@ResponseBody

: Http 응답을 처리할 때 사용하는 어노테이션, 응답 바디를 JSON, XML, 문자열 등으로 변환하여 클라이언트에게 반환할 때 사용된다.

getRequestURL

: 요청에 사용된 URL로 부터 URL 값을 리턴한다.

toString( )

: 문자열 그대로 반환한다.

HttpServletRequest는 클라이언트가 보낸 Http 요청을 담고 있다. 그렇다면 MyLogger에서 가짜 프록시를 만들도록 했으니, Http 요청이 들어오면 logDemo에서 HttpServletRequest에 가짜 프록시를 넣고 시작하게 된다. 그 후에 클라이언트가 요청한 URL 값을 가져와 문자열 그대로 반환하도록 한다. 그렇게되면 myLogger.set- 코드를 통해 MyLogger에서 URL 값이 출력된다.

- @RequestMapping 출처

- @ResponseBody 출처

- getrequestURL 출처

••• 이어서 다른 코드 부분 •••

myLogger.log("controller test");
logDemoService.logic("testId");
return"OK";

"controller test"라는 메세지와 함께 myLogger에 있는 log를 메서드를 호출한다. 그 밑에 줄은 logDemoService에 logic에 "testId"라는 메세지와 함께 logic 메서드를 호출한다. retuen "OK"는 클라이언트에게 OK라는 응답을 반환한다.

✔️  LogDemoService

주어진 id와 함께 로그를 남기는 서비스 로직을 처리

private final MyLogger myLogger;

public void logic(String id) {
    myLogger.log("service id = " + id);
}

아까 LogDemoController에  코드 쪽에 logDemoService.logic("testId");가 있었다. testId를 logic 메서드에 보내라는 의미이다. 그러면 받은 메세지를 가지고 logic 메서드는 MyLogger에 있는 log메서드에 id를 보내게 된다. 그러면 log 메서드에 필요한 uuid와 URL 그리고 id가 모두 잘 출력되게 된다.

✔️  총정리

 이번에 배운 것은 프로토타입 스코프와 웹 스코프에 관한 것이었다. 프로토타입 스코프는 싱글톤 스코프와 다르게 인스턴스를 필요할 때 마다 새롭게 받아 쓴다는 점이 있었는데, 주로 싱글톤과 함께 쓰일 프로토타입 스코프엔 큰 문제접이 있었다. 싱글톤 내부에 프로토타입 스코프를 선언하게 되면 싱글톤 스코프의 처음부터 끝가지 유지되는 특성을 그대로 가져가 새로운 인스턴스를 가져오지 못하게 된다는 것이다. 그렇기에 그 부분을 주입시점을 다르게하거나, ObjectProvider를 사용하거나, JSR-330 Provider를 사용하는 방법을 배웠다. (하지만 사실상 쓸 일이 많이 없다는 것) 

 아마 웹스코프는 웹개발을 하며 실무적으로 필요한 내용일 듯 하다. 웹스코프를 개발하면서 문제점은 request 스코프 빈이 실제 고객의 요청이 없기 때문에 오류가 발생시킨다는 점이었다. 그렇기에 가짜 프록시를 사용하여 일단 있는 척을 한 뒤, 나중에 필요한 부분에서 실제 스코프 빈이 있는 곳을 향해 생성되도록 하는 것이었다. 

 마지막 장 정리가 생각보다 오래걸렸다. 막판에 코로나 + 위경련 + 추석 등 여러 일로 인해 천천히 정리하다 결국 내용을 까먹어 다시 강의를 들어 복습하며 정리하게 되었다. 2024년 9월 22일 아직 앞에 정리했던 강의들은 다시 정리하진 않았지만, 빠르게 복습하며 앞에 정리해둔 블로그들도 다시금 손을 볼 예정이다. 

 모두들 건강하길 바라며...🎃 

코로나 휴유증으로 기력없음과 조금만 움직여도 온몸이 아픔을 겪고 있지만, 앉아서 공부하는 건 큰 기력이 들지 않아 어찌저찌 하고 있다. 오늘은 노트북 존이 있는 스터디카페에서 공부를 했는데 아주 쾌적하고 좋다. 어느 한켠엔 벌레가 있는지 삐리릭- 하고 울어 자연친화적인 느낌이 물씬난다. 피곤에 쩔어 다크서클이 코까지 내려왔지만 오늘도 화이팅!!

🧸 

🧸 구조파악 레츠꼬우- 🧸

 • lifecycle

ㄴ class : NetworkClient, beanLifeCycleTest

✔️  결과값 null

►  BeanLifeCycleTest

@Configuration
static class LifeCycleConfig {
         @Bean
         public NetworkClient networkClient() {
             NetworkClient networkClient = new NetworkClient();
             networkClient.setUrl("http://hello-spring.dev");
             return networkClient;
         }
}

- @Configuration 출처

- @bean 출처

►  NetworkClient

public NetworkClient() {
	System.out.println("생성자 호출, url = " + url); 
	connect();
	call("초기화 연결 메시지");
}

가장 첫번째 코드로 생성자 부분에서 connect( );를 수행한다. 아직 url을 setter로 받아오기전 connect( );를 수행하기 때문에 당연하게도 null 값이 나올 수 밖에 없다.

Q. 초기화 콜백을 하는 이유는?

A. 스프링 라이프 사이클을 제대로 지켜 오류 발생을 방지하기 위함이다.

✔️  초기화 콜백

►  스프링 빈의 이벤트 라이프 사이클

스프링 컨테이너 생성 - 스프링 빈 생성 - 의존관계 주입 - 초기화 콜백 - 사용 - 소멸전 콜백

: 스프링 빈이 생성된 후 의존관계 주입이 이뤄져야한다. 그런데 위의 코드처럼 주입이 모두 이뤄지고 url을 받아오지않고, 빈이 주입이 되기 전 connect( )하고자 했다. 결과값은 null로 나오며 의도대로 동작하지 못했다. 그런 부분을 줄이기 위해 초기화 콜백을 사용하는 것이다.  초기화 콜백을 코드에 넣어 의존관계가 모두 주입되고나서 그 후에 다른 부분의 동작을 수행하도록 하는 것이다.

►  초기화 콜백의 장점

1. 라이프 사이클을 따라 매번 빈이 일관된 상태에서 동작할 수 있도록 해준다.  

2. 빈이 파괴되기 전 리소스를 정리할 시간을 준다.

3. 초기화 로직을 한 곳에 모아둬서 유지보수하기 좋다.

✔️ 인터페이스 InitializingBean, DisposableBean

►  NetworkClient

    @Override
    public void afterPropertiesSet() throws Exception {
    	connect();
	call("초기화 연결 메시지");
    }

afterPropertiesSet( )

:  인터페이스 InitializingBean을 상속받으면 그 안에 정의된 afterPropertiesSet 메서드로 의존관계 주입이 끝나면 초기화를 지원한다.

    @Override
    public void destroy() throws Exception {
        disConnect();
    }

destroy( )

:  인터페이스 DisposableBean을 상속받으면 그 안에 정의된 destroy 메서드로 빈이 파괴될 때 불러온다.

결론 : 상속된 인터페이스에 정의되어있는 메서드를 가져와 쓰기 때문에 이름을 변경할 수 없다. 또한 스프링에 특화되어있는 인터페이스라서 스프링이 사용되지 않는 외부라이브러리에는 사용할 수 없다.

- InitializingBean 출처

- DisposableBean 출처

✔️  빈 등록에 초기화, 소멸 메서드 지정

►  BeanLifeCycleTest

일반적으로 사용하는 것을 추천하지 않는다.

@Bean(initMethod = "init", destroyMethod = "close")
public NetworkClient networkClient() {
    NetworkClient networkClient = new NetworkClient();
    networkClient.setUrl("http://hello-spring.dev");
    return networkClient;
}

initMethod

: 초기화 중에 빈 인스터스에서 호출할 메서드의 선택적 이름이다. 

destroyMethod

: 어플리케이션 컨텍스트를 닫을 때 빈 인스턴스에서 호출한 메서드의 선택적 이름이다. 빈 메서드에서 반환되는 객체에 대해 destroy가 있는지 유추하며 close( ), shutdown( ) 이라는 이름의 인수 없는 공개 메서드만 감지하여 자동적으로 실행한다.

- initMethod와 destroyMethod 출처

►  NetworkClient

public void init() { 
	System.out.println("NetworkClient.init"); 
	connect();
	call("초기화 연결 메시지");
}

public void close() {
         System.out.println("NetworkClient.close");
         disConnect();
}

init( )

:  initMethod를 호출할 선택적 이름이 되겠다.

close( )

: destroyMethod를 호출할 선택적 이름이 되겠다.

외부 라이브러리에 사용할 수 있다. 그 이유는 스프링 코드에 의존하는 것이 아닌, 설정 정보에 의존하기 때문이다. 하지만 스프링에서 권고하는 방식은 아니다. 더 나은 방법이 있기 때문도 있지만 이름을 명시하는 것에서 이름이 달라질 경우 컴파일 오류를 찾는 것이 어렵기 때문이다. (유지보수 측면에서도)

✔️  애노테이션 @PostConstruct, @PreDestroy

►  NetworkClient

스프링에서 가장 권장하는 방식이다.

	@PostConstruct
	public void init() {
		System.out.println("NetworkClient.init"); connect();
		call("초기화 연결 메시지");
	}
    
	@PreDestroy
	public void close() {
		System.out.println("NetworkClient.close");
		disConnect();
	}

@PostConstruct

:  의존성 주입이 완료된 후 실행되는 메서드에 사용하며 주석이 달린 메서드는 하나만 가능하다. 

@PreDestroy

:  인스턴스가 제거되고 있음을 알리는 콜백 알림이며 주석이 달린 메서드는 보유하고 있던 리소스를 해제하는데 사용한다.

- @PostConstruct 출처

- @PreDestroy 출처

코로나에 걸려 일주일은 누워있다 살아났다. 먹고 자고만 반복하니 나태함의 끝판왕이 되어버렸는데... 이렇게 다시 공부를 하려니 배로 힘든 것 같다. 8월엔 꼭 강의를 다 듣겠다고 다짐했었는데,,, 얼마 남지 않은 시간 다른 공부 제처두고 8월 안에 끝내볼까 한다. (과연 할 수 있으려나?) 아무튼 모두들 화이팅!!!!

🧸 

🧸 구조파악 레츠꼬우- 🧸

 • order

ㄴ class : OrderServiceImpl

 • annotation

ㄴ interface : MainDiscountPolicy

 • HelloLombok

 • AllBeanTest

ㄴ class : AllBeanTest

 • AutoWiredTest

ㄴ class : AutoWiredTest

✔️  OrderServiceImpl

►  생성자 주입

지금까지 사용한 방법이 되겠다.

private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;

final

: 초기화되면 변경할 수 없게 된다. 

final을 통해 생성자에 값이 제대로 설정되지 않으면 컴파일 오류를 발생시킬 수 있다. 컴파일 오류를 통해 생성자에 값을 빼먹은 걸 빠르게 알아차릴 수 있다. 그렇기에 생성자 주입 방법을 추천한다.

Q. final을 안쓰게 된다면 어떻게 되나?

A. 코드 개발이 한사람으로 이뤄지는게 아니기 때문에, 다른 개발자가 코드를 수정하게되면 오류가 발생할 수 있다. 거기다 생성자를 만들지 않으면 테스트가 돌아가지 않기 때문에 오류 수정에 용이하다. 생성자 주입에서 final을 붙여야만 코드가 돌아가는 것은 아니다. (근데 그렇데되면 생성자 코드라고 부르기 어렵지 않을까..?)

••• 이어서 다른 코드 부분 •••

@Autowired
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

@Autowired

: 의존관계를 주입해주는데, 생성자가 하나인 경우는 사용하지 않아도 자동적으로 주입이 된다.

OrderServiceImpl은 클래스  MemberRepository와 DiscountPolicy에 있는 memberRepository와 discountPolicy를 필요로 한다. 그렇기에 생성자(객체를 초기화하는 특별한 메서드)를 만들어 그 생성자가 다른 클래스의 객체를 할당받을 수 있도록 의존관계 주입이 이뤄지게 된다.

예를 들어보면, 계산을 해야하는 메서드가 있다고 가정해보자. 계산 메서드에는 회원 정보와 현재 할인 정책에 대한 정보를 필요로 한다. 그 두가지의 정보를 가져오기 위해 회원 정보와 할인 정책 정보를 가지고 있는 클래스가 필요한 것이다. 그래서 의존관계 주입을 통해 현재 클래스와 다른 두 클래스의 정보를 가져오도록 하는 것이다.

(이렇게 이해하긴 했다...)

►  수정자 주입

setter로 통해 의존관계 주입, 의존관계를 누락해도 실행은 된다.

private MemberRepository memberRepository;
private DiscountPolicy discountPolicy;

    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }

setter는 @Autowired를 사용하여 의존관계를 받게된다. 그러면 각 클래스인 MemberRepository와 DiscountPolicy에서 memberRepository와 discountPolicy에 대한 의존관계를 받는 것이다. 그렇게 객체를 final 없이 선언할 때 객체의 상태 변경을 할 수 있게 된다.

생성자 주입에서는 final을 통해 값을 변경할 수 없도록 했지만 setter는 final이 없기 때문에 객체의 상태에 변경이 가능하다. setter는 설정하려는 필드와 동일한 타입의 매개변수를 받아야하며, 자바빈 프로퍼티 규약을 통해 set---라고 메서드를 통해 정보를 수정하는 규칙이 생겼다. 

- setter를 통해 객체 상태 바꾸기 출처

Q. 생성자는 매개변수를 여러개 받을 수 있었다. setter는 하나의 매개변수만 받았다. 왜 그런것인가?

A. 생성자는 객체를 생성할 때 필요한 모든 필드에 대해 값을 주입하는 역할을 한다. ( 값을 받아서 객체를 사용하는 필드에 넣어준다는 것 같다.) 그런데 setter는 객체 상태에 수정이 들어가니 주로 하나의 매개변수만 사용한다. 꼭 setter를 사용할 때 하나의 매개변수만 사용가능한 것은 아니지만 나중에 유지보수를 생각해서 하나씩 사용한다고 한다. 실제로 setter는 사용을 지양하는 추세라고 한다. 이건 전에도 다룬적이 있던 것 같은데, 객체의 상태를 test 코드 혹은 현재 setter 코드 등에서 값을 변경할 수 있기 때문에 오류가 발생할 확률이 높기 때문이다.  

►  필드 주입

필드에 바로 의존관계 주입 (사용하지말자)

    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private DiscountPolicy discountPolicy;

OrderServiceImpl에 각 클래스 MemberRepository와 DiscountPolicy에 관한 의존관계 주입이 바로 이뤄진다.

✔️  AutowiredTest

@Test
void AutoWiredOption() {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
}

AnnotationConfigApplicationContext

:  스프링 컨테이너를 생성하며, 빈을 관리하고 의존성 주입을 처리한다.

••• 이어서 다른 코드 부분 •••

static class TestBean {

    @Autowired(required = false)
    public void setNoBean1(Member noBean1) {
        System.out.println("noBean1 = " + noBean1);
    }

    @Autowired
    public void setNoBean2(@Nullable Member noBean2) {
        System.out.println("noBean2 = " + noBean2);
    }

    @Autowired
    public void setBean3(Optional<Member> nobean3) {
        System.out.println("nobean3 = " + nobean3);
    }


}

@Autowired(required = false)

: 자동 주입할 대상이 없으면 수정자 메서드가 없으면 호출 자체가 안된다.

@Nullable

: 자동 주입할 대상이 없어도 호출은 되지만 null값이 된다.

Optional< >

: 스프링 빈이 없으면 Optional empty로 들어온다.

현재 Member 클래스에는 nobean1, nobean2, nobean3과 관련된 bean이 등록되어있지 않기에 오류가 발생할 수 있다. 하지만 각 코드를 추가하여 오류가 발생하는 것을 방지한다. nobean1의 required = true로 하게되면 오류가 발생하게된다. 

Q. AnnotationConfigApplicationContext를 선언을 따로하는 이유는 무엇일까?

A. AnnotationConfigApplicationContext가 무엇을 하는지 이해해야한다. AnnotationConfigApplicationContext은 스프링 컨테이너를 생성하는 역할을 하고 있다. 그리고 생성 후에 bean을 관리하고 의존성을 주입하게 된다. static class TestBean은 스프링 컨테이너에 의해 관리되는 빈이 된다. 만일 따로 선언하지 않고 static class TestBean에 선언하게 되면 주기가 꼬일 수 있게된다. 스프링에 의해 관리되어야할 빈이 그 안에서 스프링을 관리할 수 있도록 선언하고 있으니 주기가 꼬여 제대로 실행되지 못할 수 있다.

Q.  롬복(LomBok) 이란?

A. 코드 반복 작성을 줄여주는 코드 다이어트 라이브러리

✔️  OrderServiceImpl (LomBok)

 @Component
 @RequiredArgsConstructor
 public class OrderServiceImpl implements OrderService {
     private final MemberRepository memberRepository;
     private final DiscountPolicy discountPolicy;
}

 @RequiredArgsConstructor

: 초기화 되지않은 final 필드나, @NonNull이 붙은 필드에 대해 생성자를 생성하며, @Autowired를 사용하지 않고 의존성 주입한다.

- @RequiredArgsConstructor 출처

- 롬복 사용 예시 출처

✔️  Autowired 필드 명 매치

<기존 코드>

@Autowired
 private DiscountPolicy discountPolicy

필드가 두 개 (rateDiscountPolicy, fixDiscountPolicy)가 존재한다며 오류가 발생했다.

<변경 후 코드>

 @Autowired
 private DiscountPolicy rateDiscountPolicy

@Autowired는 DiscountPolicy를 타입의 빈을 주입하기 위해 DiscountPolicy를 찾아나서게 된다. 그런데 DiscountPolicy 타입에는 rateDiscounPolicy와 fixDiscountPolicy인 동일 타입의 빈이 두 개가 있음을 알게된다. 그렇기에 오류가 발생하고 코드를 변경하여 타입 기반에서 이름 기반 코드로 수정시켜준 것이다. rateDiscountPolicy 빈이 제대로 등록되어있다면 해당 빈으로 주입한다.

✔️  @Qualifier 사용

 @Component
 @Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

public OrderServiceImpl(MemberRepository memberRepository
		,@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {

 @Component
 @Primary
 public class RateDiscountPolicy implements DiscountPolicy {}

@Primary를 붙여서 DiscountPolicy의 타입에서 RateDiscountPolicy 빈이 가장 우선적으로 의존성 주입되도록 하는 방식이다. 메인 데이터베이스의 커넥션 획득이 필요한 경우 @Primary를 사용하고 서브 데이터베이스 커넥션 획득이 필요한 경우 @Qualify를 사용하는 것이 용이하다.

✔️  MainDiscountPolicy

애노테이션 직접 만들기

 @Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
 ElementType.TYPE, ElementType.ANNOTATION_TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Documented
 @Qualifier("mainDiscountPolicy")

@Target

: 애노테이션 적용 대상

@Retention

: 애노테이션 지속 시간 결정

@Documented

: 애노테이션 정보를 javadoc으로 작성한 문서에 포함

@Qualifier("mainDiscountPolicy")` 이렇게 문자를 적으면 컴파일시 타입 체크가 안되기 때문에 애노테이션을 직접 만들주었다. 

- 애노테이션 출처

@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy { } 

이렇게 사용이 가능해진다. 생성자 주입이나 수정자 주입에도 마찬가지로 사용가능하다.

✔️  AllBeanTest

해당 타입의 모든 빈이 필요한 경우 Map과 List를 사용한다.

►  findAllBean( )

   ApplicationContext ac
     = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);

	DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");

- getBean 출처

►  DiscountService

public DiscountService(Map<String, DiscountPolicy> policyMap,List<DiscountPolicy> policies){
            this.policyMap = policyMap;
            this.policies = policies;
}

생성자를 만들었다. 생성자는 DiscountPolicy 타입을 <빈이름, 빈> 쌍으로 받는 Map이 있고, 모든 DiscountPolicy 빈을 리스트 형태로 받는 List로 만들었다. 

••• 이어서 다른 코드 부분 •••

 public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode); 
            return discountPolicy.discount(member, price);
}

이 메서드가 할인 정책을 적용하게 한다. discountCode는 Test 코드에서 fixDiscountPolicy로 받았다. 그러면 policyMap을 통해 fixDiscountPolicy 빈을 찾아 discountPolicy라는 이름으로 받는다. 그러면 discountPolicy는 fixDiscountPolicy가 되는거고 fixDiscountPolicy의 정책인 'Vip는 얼마를 구매하든 1000원을 할인해주는 것'에 맞춰 할인이 진행된다. 그렇다면 member는 vip이며 10000원을 구매했다는 test 코드에 맞춰 1000원을 할인해주면 되는 것이다.

Map과 List를 사용하여 타입에 맞는 모든 빈을 가져온 후, 고객 혹은 테스트에 맞는 빈을 찾아 메서드를 수행하는 방식이다.

Q. 모든 빈을 가져올 때 꼭 Map과 List 둘 다 써야하는걸까?

A. 하나만 사용한다고 해서 어떤 문제가 생기는 것은 아니다. Map은 <키 혹은 이름>을 가지고 빈을 빠르게 찾는 것이고, List는 순서에 따라 모든 빈을 처리할 수 있는 특성을 가지고 있다. 현재는 적은 빈으로 테스트를 진행하고 있지만 실무는 훨씬 많은 빈으로 테스트 혹은 프로그램을 돌리기 때문에 두 특성을 모두 가지고 있어야 유연하게 적용할 수 있다.

컴포넌트 스캔까지 어찌저찌 왔다. 사실 블로그 정리만 아니었어도 강의는 한달 안에 끝냈을 듯... 그래도 블로그 정리하면서 평소 그냥 넘겼을 질문들 몽땅 찾아보는 중이다. 시간이 오래 걸리지만 그만큼 내 머리의 지식도 하나 둘 채워지고 있음을 느낀다. (사실 블로그 정리에 오랜 시간이 걸려 현타와서 주절주절 적어본다) 이번 섹션 6은 강의가 짧아서 빨리 끝날지도 모른다는 기대감이 있다. 우리집 에어컨 고장나서 안나오지만,,,🥲 더위 이겨내고! 모두들 화이팅!!!

🧸 

🧸 구조파악 레츠꼬우- 🧸

• main
  ㄴ class : AutoAppConfig
  
• test - scan
  ㄴ class : AutoAppConfigTest
  
  
• test - scan - filter
  ㄴ class : BeanA, BeanB, ComponentFilterAppConfigTest
  ㄴ Annotation : MyExcludeComponent, MyIncludeComponent

Q.  컴포넌트 스캔이란?

A. 설정정보가 없어도 자동으로 스프링 빈을 등록한다.

✔️  AutoAppConfig

컴포넌트 스캔 설정

@ComponentScan(
        basePackages = "hello.core.member",
        basePackageClasses = AutoAppConfig.class,
        excludeFilters = @ComponentScan.Filter
			(type = FilterType.ANNOTATION, classes = Configuration.class)
)

@ComponentScan

: @Component어노테이션 및 streotype(@Service, @Repository, @Controller.)어노테이션이 부여된 클래스들을 자동으로 Scan하여 Bean으로 등록해주는 역할을 하는 어노테이션이다.

basePackages

:  String으로 입력된 패캐지의 경로를 스캔하는 방법으로 직접 스캔할 위치를 지정한다.

basePackageClasses

:  적힌 클래스가(패키지 안) 위치한 곳부터 모든 어노테이션을 부여된 클래스를 bean으로 등록해준다. 

excludeFilters 

:  객체를 제외한다. (AppConfig에 수동으로 등록한 것들은 빼준다)

includeFilters

: @Component 어노테이션이 사용된 객체를 불러오고 싶으면,  includeFilters 설정을 사용한다. 특정 조건을 만족하는 클래스만을 스캔하도록 지정한다. 

- @ComponentScan 출처

- @ComponentScan 출처

Q. basePackages보다 basePackagesClasses를 쓰는걸 권장한다. 왜 그런 것일까?

A. 컴포넌트 스캔이 어떻게 동작하는지 이해해야한다. 컨포넌트 스캔을 하려면 @SpringBootApplication을 살펴봐야한다. @SpringBootApplication에는 @ComponentScan을 가지고 있고 @ComponentScan을 가지고 있는 어노테이션이 시작지점이다. @ComponentScan을 붙이고 있는 그 클래스부터 컴포넌트 스캔을 시작한다. 설정해 놓은 패키지들 중에서, 해당 패키지와 하위 패키지에 대해서 @Component 같은 스테레오 타입 어노테이션이 붙은 클래스를 모두 찾아서 빈으로 등록한다. 그러니까 이런식으로 가는게 spring에서 제공하는 기본적인 경로인 것 같다. 그런데 basePackages는 내가 직접 경로를 적는 것으로 springboot에서 제공되는 최상위 패키지부터 시작하지 않게된다는 것이다. springboot에서 제공하는 기본값을 사용하는 것이 더 효율적이고 향후 프로젝트가 커짐에 따라 복잡성을 줄여준다.

- basePackage를 권장하지 않는 이유 출처

- ComponentScan 동작 출처

••• 이어서 다른 코드 부분 •••

public class AutoAppConfig {

}

현재 AutoAppConfig 클래스의 역할은 컴포넌트 스캔을 설정하는 것이기 때문에 메서드나 다른 코드는 적지 않는다.

✔️  OrderServiceImpl

의존관계자동주입

@Component
public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
    
    ...
}

@Component

:  @Component 어노테이션을 이용하면 Bean Configuration 파일에 Bean을 따로 등록하지 않아도 사용할 수 있다. 

@Autowired

:  생성자에서 여러 의존관계도 한번에 주입받을 수 있다.

• @Component
: Bean 객체를 가져올 수 있으며(컴포넌트 스캔에 사용), IoC컨테이너 객체를 생성할 때 자동으로 객체 생성되면 Sigleton이다. 

• @Controller
: 스프링 MVC 컨트롤러에 사용하며, Dispatcher(HTTP프로토콜로 들어온 요청을 받아 적합한 컨트롤러에게 위임)은 @Controller가 있는 클래스들을 확인해서 @RequestMapping이 있는 메서드들을 확인합하여 요청을 처리한다.

• @Service
: 비지니스 로직에 있으며 저장소 계층을 사용한다.

• @Repository
: 데이터 엑세스 계층에서 사용한다. 주로 컴포너는 스캔 대상이 되기 위해 사용하지만, 스프링부트와 JPA를 사용할 경우 예외 변환기를 자동으로 등록해서 @Repository를 적용한 빈을 프록시로 변환한다.

• @Configuration
:  설정파일을 만들기 위한, Bean을 등록하기 위한 애노테이션이다. 싱글톤을 유지하도록 추가적으로 처리한다.

- @Controller, @Service 출처

- @Repository 출처

- @Configuration 출처

✔️  AutoAppConfigTest

컴포넌트 스캔이 잘 작동되는지 확인

 @Test
    void basicScan() {
        AnnotationConfigApplicationContext ac 
				 = new AnnotationConfigApplicationContext(AutoAppConfig.class);

AnnotationConfigApplicationContext는 AutoAppConfig의 인자를 받아 스프링 설정 클래스로 인식한다. AutoAppConfig에 @Configuration을 적어놓았으니 인식이 되는 것이다. AutoAppConfig에는 아까 @Componentscan에 대한 정보들을 적어놓았다. 그럼 그걸 기반으로 컴포넌트를 스캔해 빈으로 등록하고 의존성을 주입한다. 모든 준비가 완료되면AnnotationConfigApplicationContext는 완전히 초기화되며 기능을 수행하게 된다.

••• 이어서 다른 코드 부분 •••

        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberService.class);
    }

스프링 컨테이너에서 MemberService 타입의 빈을 조회한다. 조회된 빈이 MemberService타입인지 검증하여 설정이 올바르게 작동하는지 확인한다.

assertThat(A).isInstanceOf(B);

: isInstanceOf() 는 해당 타입의 인스턴스인지를 비교하는 메서드다. 

✔️  MyExcludeComponent

컴포넌트 스캔 대상에서 제외할 애노테이션

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent {

}

@interface 

: 자바에서 제공하는 어노테이션 외에, 사용자가 커스텀할 수 있는 어노테이션이다. @interface는 클래스나 변수를 특정 값으로 지정하여 관리할 수 있다.

@Target

:  사용자가 만든 annotation이 부착될 수 있는 타입을 지정한다. 

@Target({ElementType.TYPE})은 클래스, 인터페이서, Enum 또는 Record에 붙일 수 있다는 의미이다.

@Retention

: 해당 어노테이션을 언제까지 유지할건지 지정한다.

@Retention(RetentionPolicy.RUNTIME)은 Java로 작성한 코드가 돌아가는 동안 유지한다는 의미이다.

@Documented

:  어노테이션에 대한 정보가 javadoc으로 작성한 문서에 포함되도록 하는 어노테이션이다.

Q. Docummented를 써서 문서에 포함되도로 하는 이유가 무엇인가?

A. 다른 개발자가 개발된 코드를 보았을 때 어떤 코드인지 쉽게 파악할 수 있도록 해준다. 어노테이션을 왜 썼는지 등 설명을 포함시킬 수 있기 때문에 @Documented를 함께 적어 다른 개발자의 이해를 돕는다. 특히 라이브러리나 프레임워크 개발할 때 유용하다.

- @Target @Retention 출처

- @Docummented 출처

✔️  BeanB

컴포넌트 스캔에서 제외할 클래스

@MyExcludeComponent
public class BeanB {

}

아직까진 제외를 할 수 있는 어떤 기능이 실행된 것은 아니다. @MyExcludeComponent를 적어주어 아까 만들었던 애노테이션과 연결했다.

Q. 왜 애노테이션을 만드는가?

A. 애노테이션을 만드는 이유는 사용자가 원하는대로 설정 정보를 커스텀할 수 있기 때문이다. 꼭 컴포너트 스캔에 어떤 클래스를 포함하고 제외시키기 위함은 아니다. (제외는 다른 클래스에서 부여함) 아까 런타임 시간을 지정하는 것과 같이 개발자가 필요한 설정정보를 만들어 다른 클래스에 편리하게 부여할 수 있다.

✔️ ComponentFilterAppConfigTest

BeanA beanA = ac.getBean("beanA", BeanA.class);
Assertions.assertThat(beanA).isNotNull();

getBean

: ac(스프링 애플리케이션 컨텍스트)에서 beanA 이름으로 BeanA라는 타입으로 가져오는 것을 뜻한다.

Assertions.assertThat(A).isNotNull( )

: A가 Null인지 확인한다.

- Assertions.assertThat().isNotNull() 출처

assertThrows(
        NoSuchBeanDefinitionException.class,
        () -> ac.getBean("beanB", BeanB.class));
}

NoSuchBeanDefinitionException

: BeanFactory정의를 찾을 수 없는 빈 인스턴스를 요청했을 때 예외가 발생한다.

NoSuchBeanDefinitionException.class, () -> ac.getBean("beanB", BeanB.class)은 BeanB를 beanB라는 이름으로 가지고 왔는데 그게 정의를 찾을 수 없는 빈 인스턴스여야 테스트가 성공하는 것이다.

- NoSuchBeanDefinitionException  출처

••• 이어서 다른 코드 부분 •••

@ComponentScan(
            includeFilters = @Filter(classes = MyIncludeComponent.class),
            excludeFilters = @Filter(classes = MyExcludeComponent.class)
    )

@Filter

: 필터는 주로 요청에 대한 인증, 권한 체크 등에  쓴다. 구체적으로 들어온 요청이 DispatcherServlet에 전달되기 전, 헤더를 검사해 인증 토큰이 있는지 없는지, 올바른지, 옳지 않은지 등을 검사한다.

- Filter 출처

excludeFilters

:  속성을 사용하여 특정 대상을 스캔에서 제외시킨다.

Q. 그럼 다시 포함시키고 싶으면 어떻게 해야하나?

A. includeFilters = @Filter(classes = MyExcludeComponent.class)로 바꿔주면 된다.

- excludeFilters 출처

@ComponentScan을 통해 속성을 살펴본다. 속성엔 MyExcludeComponent를 excludeFilters하라고 적혀있다. 그러면 MyExcludeComponent를 제외시키도록 되어있으니 @MyExcludeComponent가 붙어있으면 제외시키도록 한다. 그런데 BeanB에는 @MyExcludeComponent가 붙어있으니 제외가 되었다.

🌷

컴포넌트 스캔이 필요한 경우 @ComponentScan을 쓰고 { } 안에 원하는 특성을 넣을 수 있음을 알아봤다.

그리고 컴포넌트 스캔에 대한 요구를 설정하고 싶은 겨우 @interface와 클래스를 연결시킬 수 있다.

만일 결과값이 강의와 다르게 나온다면,

AppConfig의 MemberRepository 앞에 static이 붙어있는지 확인하라!

Q. 왜 static을 쓰면 인스턴스 값이 다르게 할당될까?

A. static을 붙이게 되면 spring의 bean 라이프 사이클 관리가 정상적으로 이루어지지 않기 때문에 같은 타입의 bean이 여러 인스턴스로 생성되게 된다.

👁️‍🗨️  static 이란?

1. 클래스 레벨의 변수나 메소드에 사용되며, 이를 통해 객체 생성 없이 해당 변수나 메소드에 접근할 수 있습니다.

2. static 멤버는 클래스가 메모리에 로드될 때 단 한 번만 생성되며, 모든 인스턴스가 공유하는 공통의 자원이 됩니다.

3. 클래스 단위로 관리되어 메모리 사용량을 줄이고, 객체 생성 오버헤드 없이 접근할 수 있다.

- Static 출처

👁️‍🗨️  static이 spring의 라이프 사이클을 어떻게 꼬는 것인가?

(정확하게 이해한 건 아닙니다🥲)

1. 원래 spring의 라이프 사이클은 @Configuration 클래스의 인스턴스를 생성하고 @bean 메서드를 호출해야한다.

2. 그런데 static을 bean 메서드에 정의하게 되면, static의 특성인 객체 생성 없이 해당 변수나 메소드에 접근하기 때문에  1번의 사이클을 따라가지 않게 된다. 

3. 그렇기에 메서드가 클래스 레벨에서 호출되어(static의 특징) @Configuration의 인스턴스 생성 없이도 메서드를 호출하게 되고 spring의 라이프 사이클을 깨게 만들어 싱글톤 보장을 해주지 못하게 된다.

👁️‍🗨️  static과 spring bean의 차이점은 무엇인가?

- static과 bean의 공통점과 차이점 출처

과연 스프링은 어떤 이점을 가지고 있을까? 실제로 웹사이트를 운영하게 되면 고객의 동시 요청을 처리하게 된다. 매번 고객의 요청을 처리할 때 마다 새로운 객체를 생성하게 되면 메모리 과부하가 오고 비효율적으로 운영하게 될 것이다. 스프링은 이런 경우 어노테이션을 이용하여 간단한 코드로 싱글톤 패턴을 유지시켜주며 개발자가 효율적이게 관리할 수 있도록 도와준다. 싱글톤 패턴이 무엇이며 스프링이 어떤 식으로 싱글톤을 관리해주는지 알아보자.

🧸 

🧸 구조파악 🧸

•  singleton
  ㄴ class : SingletonService, SingletonTest, StatefulService, StatefulServiceTest, ConfigurationSingletonTest 
• AppConfig

Q.  스프링을 사용하는 이유는?

A. 싱글톤이 보장되기 때문이다.

✔️  SingletonTest

► pureContainer

순수 자바코드로 생성자를 직접 호출한다.

AppConfig appConfig = new AppConfig();

MemberService memberService1 = appConfig.memberService();
MemberService memberService2 = appConfig.memberService();

스프링 컨테이너를 이용하지 않고 직접 AppConfig의 객체를 생성했다. appConfig에 있는 memberService 메서드를 이용하는데 타입은 MemberService이며 각 이름은 memberService1과 memberService2가 된다.

위의 코드는 싱글톤 패턴을 가진 클래스를 이용하지도, 스프링을 이용하지도 않았기 때문에 memberService1과 memberService2는 서로 다른 객체를 가질 것이다. 실제 프로그램에서는 다수 고객의 동시 요청이 발생한다. 고객이 요청할 때마다 AppConfig는 객체를 새로 생성해야한다. 이 많은 요청마다 새로운 객체를 만드는 것은 메모리 낭비를 유발한다.

▸  결과

각 값이 6a472554와 7ff2a664로 다른 것을 확인할 수 있다. 객체가 다르게 생성되었다는 것을 의미한다.

••• 이어서 다른 코드 부분 •••

Assertions.assertThat(memberService1).isNotSameAs(memberService2);

assertThat(A).isNotSameAs(B)

: 대상 A와 대상 B의 주소값이 다른지 확인하는 메서드

Q. assertThat(A).isEqualTo(B)와 assertThat(A).isSameAs(B)와 차이점은 무엇인가?
A. isEqualTo는 대상의 내용을 비교하고 isSameAs는 대상의 주소값을 비교한다.

예시) isEqualTo

String A = "Hi";
String B = "Hi";

assertThat(A).isEqualTo(B);​

예시) isSameAs (==)

String A = "Hi";
String B = A;

assertThat(A).isSameAs(B);

✔️ SingletonService

싱글톤 디자인 패턴을 구현했다.

private static final SingletonService instance = new SingletonService();

private

: 외부에서 접근할 수 없게 한다.

static

:  instance 변수가 클래스 수준에서 관리되게 하며, 클래스가 메모리에 로드될 때 인스턴스가 생성되고 프로그램 종료될 때까지 유지된다.

final

: 인스턴스가 한 번 생성되면 변경할 수 없다.

Q. 싱글톤 패턴에 static은 왜 쓰는걸까? 

A.  static은 인스턴스(메모리 위에 올라간 객체)를 새로 생성하지 않아도 접근 가능하게 한다. 싱글톤 패턴은 단순히 하나의 인스턴스만 생성하는 것이 아니다. 하나의 인스터스를 생성 후 공유해 사용하도록 한다. 여기서 static은 하나의 인스턴스를 생성되도록 하며, 전역적으로 공유(사용)하도록 하게 해준다. private와 final의 역할은 외부에서 변경할 수 없도록 해준다.

- 싱글톤 패턴과 static의 관련 출처

Q. 객체와 인스턴스의 차이

A. 객체는 선언, 인스턴스는 실체화를 의미한다. 객체는 클래스의 타입으로 선언되었을 때, 인스턴스는 그 객체가 메모리 위에 올려졌을 때를 말한다. 그러니까 특별한 객체를 인스턴스라고 한다. (용어의 의미가 조금 다를 뿐, 객체와 인스턴스는 같다고 보면 되는 것 같다.)

Dog myDog = new Dog(); 
Dog anotherDog = new Dog();

위의 두 코드에서 myDog와 anotherDog는 Dog 클래스의 객체이자 인스턴스임을 나타낸다. 즉, 객체지만 인스턴스가 아닌 경우는 없다고 한다.

- 객체와 인스턴스의 차이점 출처

•••그 다음 코드 •••

public static SingletonService getInstance() {
        return instance;
    }

SingletonService의 인스턴스를 새로 만들지 않고, getInstance( ) 메서드를 통해 인스턴스를 접근한다. 
그러니까 static으로 전역적으로 공유된 것을 사용하게 해주는 메서드가 getInstance( )인 듯 하다.

  private SingletonService() {

    }

생성자

: 인스턴스를 만들 때 호출되는 특별한 메서드

Q. 생성자가 정확하게 무엇인가?

A. 객체가 생성될때 자동으로 호출되는 특수 목적의 멤버함수(메소드)로 객체의 초기화를 위해 사용한다. 무조건 클래스당 하나가 있어야하며, 객체가 생성됐는데 그에 맞는 생성자가 없을 경우 컴파일러가 자동으로 기본생성자를 생성하거나 오류가 발생할 수 있다. 

	public Book() {	}                          // 기본생성자
	
	public Book(String title, int price) {    // 매개변수를 가진 생성자
		this.title = title;
		this.price = price;
	}

 

		Book b1 = new Book();                // 객체생성 - 기본생성자 호출됨
		Book b2 = new Book("국어책", 3000);   // 객체생성 - 매개변수를 가진 생성자 호출됨

- 생성자에 대한 설명 출처

Q. 그렇다면 위의 생성자는 기본 생성자인가? 왜 쓰는걸까?

A. 위의 생성자는 기본생성자와 차이가 있다. 일단 기본 생성자는 public을 기반으로 하는데, 위의 코드는 private로 개발자가 정의한 명시적 생성자(매개변수가 없는)다.  private를 사용한 이유는 싱글톤 패턴을 만들기 위해 외부에서 인스턴스를 만들 수 없도록 하기 위함이다.

••• 연결된 테스트 코드 확인하기 •••

✔️  SingletonTest

► singletonServiceTest

SingletonService singletonService1 = SingletonService.getInstance();
SingletonService singletonService2 = SingletonService.getInstance();

SingletonService의 코드를 생각해보면 인스턴스를 외부에서 만들지 못하도록 private 생성자를 만들었다. 그리고 static, final, private로 인스턴스 변경을 불가하게 만들었다. 그런데 전역적으로 공유를 하기 위해 getInstance 메서드를 만들었다.

getInstance( )를 통해 접근하여 singletonService1과 singletonService2의 인스턴스를 반환받는 것이다. 생성자를 직접 호출하지 않고 클래스 내에서 관리하는 유일한 인스턴스를 반환하는 정적 메서드를 사용하는 것이다.

► singleton 메모리 동작 살펴보기

# SingletonService
private static final SingletonService instance = new SingletonService();

# SingletonTest
SingletonService singletonService1 = SingletonService.getInstance();
SingletonService singletonService2 = SingletonService.getInstance();

클래스가 로딩되면 instance 변수가 메서드 영역에 적재된다. 그런데 이때 instance 실제 값이 메서드 영역에 있는 것이 아니라, instance라고 이름만 붙여진 껍데기만 메서드 영역에 있으며 실제 객체는 힙 영역에 저장되어있다. 메서드 영역에는 힙 영역에 있는 실제 객체값을 가리키는 주소값 위치가 존재한다.

singletonService1은 스택 영역에 생성되게 된다. 그러면 singletonService1은 메서드 영역의 instance가 가리키는 힙의 주소를 복사하여 저장한다. 그 후 singletonService2가 생성되어도 singletonService1와 같이 메서드 영역이 가리키고 있는 instance 힙의 주소를 복사하여 저장한다. 그래서 여러개를 생성해도 하나의 객체만 가리키게 되는 것이다.

만약 static을 붙이지 않게 되면 instance는 메서드에 적재되지 않고 힙에 적재된다. 이때 스택에는 객체 사용을 요구하는 변수가 들어오게 되면 힙 영역에 있는 instance는 계속해서 만들 수 있는 특성을 가지게 되기 때문에 new SingletonService( )를 호출하여 재귀적으로 instance의 새로운 객체를 반환한다.

► 결론

싱글톤 패턴을 사용하면 DIP,OCP를 위반할 수 있다. 더구나 private 사용으로 인해 유연성도 떨어진다.

그렇기에 스프링 컨테이너를 사용하여 인스턴스를 싱글톤으로 유지하는 방식을 사용할 것이다.

✔️ SingletonTest

► springContainer

// 스프링을 사용하기 위해 아래 코드 정의
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

MemberService memberService1 = ac.getBean("memberService", MemberService.class);
MemberService memberService2 = ac.getBean("memberService", MemberService.class);

AppConfig에 정의되어있는 memberService라는 이름을 가진 빈을 MemberService 타입으로 반환한다. 이때 스프링 컨테이너의 특성에 의해 같은 빈 인스턴스를 할당한다.

같은 결과값이 나온 것을 확인할 수 있다.

✔️  StatefulService

객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 무상태로 설계해야한다.

► 상태를 유지하도록 설계할 경우 발생하는 문제점

# StatefulService
private int price; 

public void order(String name, int price) { 
	...
	this.price = price; 
}

# StatefulServiceTest

statefulService1.order("userA", 20000);
statefulService2.order("userB", 10000);

int price = statefulService1.getPrice();
System.out.println("price = " + price);

처음에 order에 20000이 들어왔다. 그러면 this를 통해 들어온 값은 필드에 있는 price로 들어가면서 값이 공유된다. 그리고나서 userB가 10000을 주문했다. 그러면 다시 필드는 10000의 값을 가지게 된다. 값이 즉각적으로 돌려지는 방식이 아닌 이렇게 상태를 유지하는 방식으로 설계했기 때문에 최종적으로 price의 값은 10000이 되고 그 후에 statefulService1의 price를 출력하니 마지막 상태였던 10000이 나오게 된다.

► 무상태로 설계하기

public int order(String name, int price) {
        ...
        return price;
    }

order 메서드가 가격을 바로 반환하도록 설계하면 된다. 이렇게하면 상태를 유지하지 않고, 각 요청이 독립적으로 처리될 수 있다.

✔️  StatefulServiceTest

► TestConfig

 	@Bean
        public StatefulService statefulService() {
            return new StatefulService();
        }

@Bean을 써서 간단한 설정 클래스를 만들었다.

•••그 다음 코드 •••

	StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

statefulService1과 statefulService2의 인스턴스를 요구한다. 그러면 TestConfig에 있는 StatefulService로 가서 인스턴스를 생성하고 반환한다.

•••그 다음 코드 •••

	int userAprice = statefulService1.order("A", 2000);
        int userBprice = statefulService2.order("B", 1000);

StatefulService의 order 메서드를 호출한다. 순서대로 내부상태필드 price에 각 값을 저장하고 이 값을 반환한다.

✔️  자바 코드의 싱글톤 유지법

► AppConfig

    @Bean
    public MemberService memberService() {
        System.out.println("call AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());
    }
    
    @Bean
    public MemberRepository memberRepository() {
        System.out.println("call AppConfig.memberRepository");
        return new MemoryMemberRepository();
    }
    
    @Bean
    public OrderService orderService() {
        System.out.println("call AppConfig.orderService");
        return new OrderServiceImpl(memberRepository(), rateDiscountPolicy());
    }

코드를 살펴보면 memberService에서 memberRepository가 호출되고 memberRepository에 있는 MemoryMemberRepository가 호출된다. memberRepository에서 MemoryMemberRepository가 호출된다. orderService에서 memberRepository가 호출되고 memberRepositorysms MemoryMemberRepository를 호출한다. 그렇게 총 3번의 MemoryMemberRepository가 호출되는 것으로 보이면서 싱글톤이 깨져보인다. 과연 진짜로 싱글톤이 깨지는지 확인해보자.

► MemberServiceImpl

    public MemberRepository getMemberRepository() {
    	return memberRepository;
    }

memberRepository가 private final로 정의되어있기에 외부 테스트 클래스에서 memberRepository를 사용하기 위해getMemberRepository를 이용하여 객체를 가져온다. 이때 memberRepository는 인터페이스로 MemoryMemberRepository에 상속되어있다.

► ConfigurationSingletonTest

        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();

        System.out.println("memberService -> memberRepository1 = " + memberRepository1);
        System.out.println("orderService -> memberRepository2 = " + memberRepository2);
        System.out.println("memberRepository = " + memberRepository);

memberService와 orderService는 getMemberRepository를 통해 memberRepository의 객체를 출력한다. 출력 결과 memberRepository는 같은 인스턴스가 공유되어 사용하고 있음을 알 수 있다. 

► 이유에 대하여

@Configuration
public class AppConfig {

@Configuration이 붙게되면 AppConfig는 내가 만든 클래스가 아닌 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고 그 다른 클래스를 스프링 빈으로 등록한 것을 알 수 있다. 즉 AppConfig에 AppConfig@CGLIB가 오버라이딩 되어서 실제 실행은 AppConfig@CGLIB가 된 것이다.

만약 @Configuration을 붙이지 않으면 @Bean이 붙은 메서드가 호출될 때마다 새로운 인스턴스를 생성하게 될 것이다.

🌷

이렇게 싱글톤을 어떻게 만드는지, 스프링이 싱글톤을 어떤 방식으로 보장해는지에 대해 알아보았다.

스프링 컨테이너 자체적으로 빈을 한 번만 생성하고 재사용하는 것도 알게되었지만,

@Configuration을 통해 자바 코드도 같은 방식으로 동작하게 한다는 걸 알 수 있었다.

컨테이너를 생성했다. 스프링 컨테이너 내에서 빈 이름과 빈 객체를 저장하여 관리해준다. Public과 함께 쓴 것은 타입과 이름이 된다. 예시로 public MemberService memberService( )의 경우 MemberService는 타입이 되고 memberService는 빈의 이름이 된다. return new와  함께 쓰이면 빈 객체과 된다. 예로 return MemberServiceImpl(memberRepository( ))의 경우 MemberServiceImpl이 빈 객체가 되는 것이다. 그렇게 스프링 컨테이너에 저장되어 관리된다. 그리고 이번엔 빈이 제대로 등록되어있는지 확인하는 방법을 배울 것이다.

[ ◀︎ ]

🧸

잘못된 정보가 있다면 댓글로 남겨주세요

🧸 구조파악 레츠꼬우- 🧸

test에 총 3가지의 패키지를 만들었다.

• beanfind
  ㄴ ApplicationContextInfoTest, ApplicationContextBasicFindTest, ApplicationnContextExtendsFindTest
       , ApplicationContextSameBeanFindTest
• beandefinition
  ㄴ BeanDefinitionTest
• xml
  ㄴ XmlAppContext

✔️  beanfind_ApplicationContextInfoTest

►  findAllBean

: 내부에 포함된 Bean을 출력한다.

AnnotationConfigApplicationContext ac 
= new AnnotationConfigApplicationContext(AppConfig.class);

AnnotationConfigApplicationContext

: Bean으로 지정된 객체들을 가지고 있는 context고 컨테이너라고도 부른다.

ApplicationContext는 인터페이스로 다양한 구현체를 가지고 있다. 그 중 하나가 어노테이션을 이용할 수 있도록 해주는 AnnotationConfigApplicationContext이며 현재 강의에서 다루는 것이다. 섹션 4 강의에서 AppConfig에 @Configuration과 @Bean 어노테이션을 정의했다. 이렇게 어노테이션을 정의를 통해 빈을 새롭게 생성하거나 관리하고, 컴포넌트 스캔 혹은 프로파일 관리를 할 수 있게 된다.

ㅤ- ApplicationContext 설명 출처

- AnnotationConfigApplicationContext 출처

-  AnnotationConfigApplication  출처

••• 이어서 다음 코드 •••

String[] beanDefinitionNames = ac.getBeanDefinitionNames();

getBeanDefinitionNames( )

: 팩토리에 등록된 모든 bean을 반환하고 @bean을 제외한 다른 방법으로 등록된 싱글톤 Bean은 무시한다. 또한 계층구조도 무시한다. 

ac는 AppConfig에 등록된 bean에 대한 설정 정보가 담겨있다. 하지만 getBeanDefinitionNames는 내부의 모든 bean을 반환한다고 정의되어있는데, 그 이유를 살펴보면 AppConfig의 설정을 적용하면서 Spring에 기본적으로 필요로하는 내부 빈들도 자동적으로 함께 등록되기 때문이다. 그렇기에 내부 빈들도 모두 보고 싶을 경우 getBeanDefinitionNames()를 사용한다.

- getBeanDefinitionNames 정의 출처

ㅤㅤ••• 그 다음 코드 •••

for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println ("name = " + beanDefinitionName + "object = " + bean); }

getBean( );

: 현재 사용 중인 bean을 반환한다.

Object

: 최상위 클래스로 자바 클래스에 따로 extends하지 않으면 java.lang.Object를 상속한다. 필드가 아닌 메서드로 구성되어있으며 모든 타입을 다 받을 수 있다.

beanDefinitionNames는 모든 빈을 반환 받아온 문자열이다. for문을 이용하여 beanDefinitionNames에 들어있는 빈 이름을 beanDefinitionName 변수에 저장한다.  그리고 ac.getBean을 이용하여 빈 객체를 조회하며 이때 bean에 저장되는 타입은 Object로 모든 타입을 다 받을 수 있게 된다. 그렇기 때문에 스프링 내부에 있는 빈까지 모두 출력할 수 있는 것이다.

아래 <결과>를 보면 name은 빈의 이름이 출력되었고 object는 지정된 클래스가 무엇인지 출력되었다. 즉 discountPolicy는 hello.core.discount.RateDiscountPolicy와 연결되어있음을 보여주는 것이다.

<결과>
name = discountPolicy
object = hello.core.discount.RateDiscountPolicy@246f8b8b

요딴식으로 출력된다.🐻

Q.꼭 beanDefinitionName 변수로 받아줘야하는건가? 

A. 꼭 그럴필요는 없다. 가독성을 위해 변수를 사용하는 것 뿐.

String[] beanDefinitionNames = ac.getBeanDefinitionNames();
for (int i = 0; i < beanDefinitionNames.length; i++) {
    String beanName = beanDefinitionNames[i];
    System.out.println("Bean Name " + (i + 1) + ": " + beanName);
}​

이런식으로 그냥 변수없이 받아도 된다고 한다. 그리고 받아온 걸 beanName에 저장하여 출력한다.

Q.ac.getBean에서 ac는 꼭 붙여하는걸까? 

A. getBean은ApplicationContext에서 제공하는 인터페이스 메서드이다.그렇기에 관련 ApplicationContext에서 제공하는 메서드를 쓰려면 내가 지정한 변수(ac)를 꼭 붙여써야 한다.

- getBean 출처

- Object 출처

►  findApplicationBean

: 내가 개발한 bean 출력하기.

for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

모든 빈을 getBeanDefinitionNames로 가져왔다. 그리고 for을 통해 모든 빈의 메타정보를 getBeanDefinition으로 beanDefinition에 저장할 것이다.

getBeanDefinition( );

: 특정 bean의 메타정보를 가져온다.

BeanDefinition

: 스프링 프레임워크에서 정의한 인터페이스로, 스프링 컨테이너에서 관리하는 각 bean의 메타정보를 나타내는 역할을 한다.

Q. 위의 코드 중 getBean에서는 Object라는 객체 타입을 적었는데 여기서는 왜 BeanDefinition을 적을걸까?
getBean도 정보를 가져오는 코드인거 아닌가? 현재 사용중인 bean을 반환하는 것이니. 그런데 왜 다르게 쓰는걸까?

A. getBean()과 getBeanDefinition( )은 컨테이너를 가져오는 방식이 다르다. getBean()은 스프링 컨테이너에서 빈의 실제 인스턴스를 가져오고(쉽게 말해서 bean과 연결된 클래스) Object 타입으로 반환한다. 반면에 getBeanDefinition()은 특정 빈의 메타정보를 가져온다. 그리고 가져온 메타정보를 정의해주는 인터페이스가 BeanDefinition이 되기에 빈의 이름이 호출되면 BeanDefinition 객체로 반환하는 것이다. 즉 Object와 BeanDefinition을 써야하는 경우가 완전히 다르며 BeanDefinition은 하나의 구체적인 타입이 아니다.

Q. getBean( ) 메서드는 일반적으로 Object로 받는다고 한다. 그렇다면 왜 일반적으로 Object로 받는가?

A. 빈의 실제 타입이 무엇이든지 상관없이 처리할 수 있게 하기 위해 Object로 받는다. (유연성과 일관성을 갖게 된다)

ㅤㅤ•••그 다음 코드 •••

if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                Object bean = ac.getBean(beanDefinitionName);
                System.out.println("name = " + beanDefinitionName 
                + "object = " + bean); }

getRole

: 해당 역할을 반환한다. 정수값으로 반환한다.

ROLE_APPLICATION

: 사용자가 정의한(내가 만든) 빈이다. 정수값은 2

• ROLE_SUPPORT : 스프링 내부에서 지원하는 역할을 가진 빈이다. 정수값은 4
• ROLE_INFRASTRUCTURE : 스프링의 내부 구조를 지원하는 빈이다. 정수값은 8

for문으로 모든 빈의 메타정보를 가져왔고(beanDefinition), 그 메타정보를 if문을 통해 사용자가 정의한 빈인지 아닌지 구분할 것이다. beanDefinition에 있는 정보를 getRole을 통해 역할이 무엇인지 확인한다. 그 역할이 ROLE_APPLICATION인지 확인하여 맞으면 괄호 안에 있는 코드가 실행되도록 한다. 여기서BeanDefinition.ROLE_APPLICATION으로 쓴 이유는 ROLE_APPLICATION이 BeanDefinition 클래스 안에 선언되어있기 때문에 이런 형태로 적어야 제대로 작동한다.

beanDefinitionName(모든 빈을 반환되어 저장한 변수)에서 조건에 맞는 빈을 꺼내 Object 타입인 bean에 저장한다.

Q. 무조건 getBean( )과 Object를 통해서만 받아야 결과가 출력되는가?
ㅤ
A. 그렇다. 실제 빈의 인스턴스를 얻어와야만 결과값으로 출력할 수 있다고 한다. getRole( )은 해당 역할을 반환하는 것 뿐, 인스턴스를 반환할 수 없다. 그렇기때문에 실제 인스턴스를 반환해주는 getBean( )을 사용해야만 결과를 볼 수 있다. getBean(타입) 혹은 getBean(빈이름, 타입)을 적으면 조회가 된다.

- getRole 출처

- getRole의 상수 출처

✔️  beanfind_ApplicationContextBasicFindTest

►  findBeanByName

: 빈 이름으로 조회하기.

MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);

assertThat( ).isInstanceOf( )

: 해당 타입의 인스턴스인지를 비교하는 메서드이다.

bean 이름 중에서 memberService이며 해당 타입을 MemberService로 지정한 빈을 MemberService(인터페이스 타입으로)가지며 변수 이름은 memberService으로 받겠다는 것이다. 그리고 그 MemberServiceimpl(구체클래스)이 memberService의 인스턴스인지 비교한다.

좀 더 쉽게 설명해보자면, AppConfig에 인터페이스와 메서드 명을 같이 적었고 return 값으로 구체클래스를 적었다. 여기서 확인하는 것은 AppConfig에 적은 인터페이스와 구체클래스가 맞는지 확인하는 것이고 "memberService"를 적어 이름으로 조회하는 방법이다.

►  findBeanByNameX

: 빈 이름으로 조회하지 않기.

 assertThrows(NoSuchBeanDefinitionException.class,
                () -> ac.getBean("XXXX", MemberService.class));

assertThrows

: JUnit 또는 AssertJ와 같은 테스트 프레임워크에서 예외가 발생하는지를 테스트할 때 사용한다. 발생된 예외 타입과 예상되는 예외 타입이 일치하면 테스트는 성공한다.

NoSuchBeanDefinitionException.class

: 정의를 찾을 수 없는 Bean 인스턴스를 요청했을 때 예외가 발생한다.

() -> 람다식

: (매개변수)가 들어가고 -> 시작부분을 가리킨다.

-> (시작부분)으로 가서 XXXX가 MemberService.class의 해당 빈으로 존재하지 않으면 NoSuchBeanDefinitionException 예외를 발생시킨다.

- assertThrows 출처

- NoSuchBeanDefinitionException 출처

- 람다식 출처

✔️  beanfind_ApplicationContextSameBeanFindTest

    @Configuration
    static class SameBeanConfig {
        @Bean
        public MemberRepository memberRepository1() {
            return new MemoryMemberRepository();
        }
        @Bean
        public MemberRepository memberRepository2() {
            return new MemoryMemberRepository();
        }
  }

AppConfig를 수정하기 싫으니, 이렇게 같은 타입의 같은 구체클래스를 반환하는 두개의 bean을 만들었다.

►  findAllBeanByType

Map<String, MemberRepository> beansOfType =
	ac.getBeansOfType(MemberRepository.class);

getBeansOfType

: 타입을 파라미터로 받는다. Bean 이름을 key로 객체를 value로 하는 Map을 반환한다. 주로 특정 타입에 여러 개의 빈이 있을 경우 오류를 발생시키지 않기 위해 사용한다.

MemberRepository 타입에 있는 빈을 getBeansOfType 메서드를 통해 key와 value를 반환한다. 그러면 String에 bean의 이름이 들어가고 MemberRepository에 실제 bean의 객체가 들어가게 된다. 그렇게 MemberRepository 타입에 bean이 여러 개인 경우 BeansOfType 변수에 모두 담을 수 있게 된다.

ㅤㅤ•••그 다음 코드 •••

       for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value = " +
beansOfType.get(key));
        }

KeySet

: Map의 모든 key를 가져와 Set객체로 반환한다. for-each 루프를 사용하여 순차적으로 접근하고, 각 key를 사용하여 value에 접근할 수 있다.

beansOfType에 있는 모든 key(빈의 이름)를 가져와 반복하여 변수 key에 넣는다. 그리고 get(key)를 통해 그 key(빈의 이름)에 해당하는 값을 beansOfType에서 가져온다. 여기서 beansOfType은 key와 MemberRepository를 저장하고 있는 변수명으로, get(key)는 빈의 이름에 맞는 객체를 가져오라는 의미가 된다.

ㅤ•••그 다음 코드 •••

  System.out.println("beansOfType = " + beansOfType);
        assertThat(beansOfType.size()).isEqualTo(2);

beansOfType은 모든 bean의 이름과 객체를 저장하고 있으니, 그것을 모두 출력한다.  assertThat을 이용하여 beansOfType에 있는 bean의 개수가 2개가 맞는지 확인하는 코드가 된다.

- getBeansOfType 출처

- KeySet 출처

✔️ XML

<bean id="memberService" class="hello.core.member.MemberServiceImpl">
         <constructor-arg name="memberRepository" ref="memberRepository" /> 참조
</bean>
     
                                   실제 구현 객체
<bean id="memberRepository" class="hello.core.member.MemoryMemberRepository" />

GenericXmlApplicatonContext

: 스프링 설정 파일을 읽어와 로딩 시키고, 객체를 생성하며 초기화하는 역할을 한다.

- GenericXmlApplicationContext 출처

.

혼자 천천히 공부하며 작성했습니다.

잘못된 내용이 적혀있을 수 있으니, 감안하고 봐주시면 감사하겠습니다.

🍀 모두들 화이팅하세요 🍀