[Tech Study] 11월 Spring Team2

 안녕하세요 ! GDSC Sungshin Spring Team2  팀입니다.

 

GDSC Sungshin은 9월부터 12월까지 기술 스터디를 진행하는데요! 

11월(6주차 ~9주차) Spring Team2는 무엇을 했는지 공유하겠습니다 :)

11월에는 스프링 핵심원리 강의를 섹션0~섹션 5를 듣고,

매주 대면으로 만나기 전에 매주 정해진 분량의 강의를 수강한 후, 블로그에 핵심내용을 정리 하였습니다.

추가적으로 활발한 대면 스터디를 위해 배운 내용 중에서 퀴즈를 각자 한개씩 만들어 Notion에 업로드 하였으며,

대면으로 각자 만들어온 퀴즈도 풀고, 매주 발표자를 정해 배운 내용을 가볍게 발표하는 형식으로 진행하였습니다.

섹션3에는 객체지향 원리 5가지중 OCP,DIP,SRP를 실습코드 예제를 통해서 집중적으로 학습하였습니다.  

 

또한 AppConfig클래스에 Bean을 등록하여 의존관계 주입하여 애플리케이션을 크게 사용영역과,

구성하는 영역으로 분리하는 방법을 배웠습니다.

 

• AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(configuration)하는 영역으로 분리되었다.
• MemberServiceImpl은 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정된다. 그래서 생성자를 통해 어떤 구현객체가 들어올지 알수가 없다. 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행만 집중하면 된다.
• FixDiscountPolicy->RateDiscountPolicy로 변경해도 구성 영역만 영향을 받고, 사용 영역은 전혀 영향받지 않는다.

 

섹션4에는 스프링 컨테이너와 스프링빈 개념에 대해 학습하였습니다.

 

BeanFactory(빈관리 및 조회기능)+편리한 부가기능 =ApplicationContext =스프링 컨테이너

여기서 부가기능은 메세지 소스를 활용한 국제화기능, 환경변수, 애플리케이션이벤트, 편리한 리소스 조회등등이 있다.

 

- 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정(구성) 정보로 사용한다.

→여기서 @Bean이 라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다. 그 후 빈을 생성하고→의존성을 주입하고→스프링 컨테이너는 빈의 초기화 작업을 수행하고 빈이 초기화 된 후→ 스프링 컨테이너나 애플리케이션에서 빈을 사용하고→스프링컨테이너가 종료될 때 또는 필요한 경우에 빈의 소멸 작업을 수행한다.

 

부모타입으로 조회하면, 자식 타입도 함께 조회된다.

그래서 모든 자바 객체의 최고 부모인 Object타입으로 조회하면 모든 스프링 빈을 조회한다.

 

웹애플리케이션은 고객이 계속 요청을 함

요청이 참 많음~ 이러한 요청을 어떻게 처리할까?

우리가 만들었던 스프링 없는 순수한 DI컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다.

초당 50000개의 요청이 들어오면 초당 50000개의 객체를 생성할 수 도 있음->메모리 낭비가 심하다!

​

해결방안 : 해당 객체가 딱 1개만 생성되고 공유하도록 설계하면 된다. 이것이 싱글톤 패턴이다.

 

싱글톤 패턴 : 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

 

 

 

 

11월에는 유진 멤버가 스터디 진행상황 발표를 담당해주셨어요 :) 너무 잘해주셔서 감사해요 ㅎㅎ