스프링 핵심 원리 - 기본편좋은 객체지향 설계의 5가지 원칙SRP: Single responsibility principle(단일 책임 원칙)하나의 클래스는 하나의 책임만중요한 기준: 변경 -> 변경 발생시 파급효과가 적다 = 단일 책임 원칙을 잘 따른 것OCP: Op
스프링은 다음 기술을 통해 다형성 + OCP, DIP를 가능하게 지원DI(Dependency Injection): 의존관계/의존성 주입DI 컨테이너 제공클라이언트 코드의 변경 없이 확장 가능모든 설계는 "역할"과 "구현"을 분리하자이상적으로는 모든 설계에 인터페이스를
제어의 역전: IoC(Inversion of Control)프로그램의 제어 흐름을 직접하기보다는, 외부에서 관리하는 것ex) AppConfig에서 구현체 생성프레임워크 vs 라이브러리프레이워크: 내가 작성한 코드를 제어하고 대신 실행 (ex. JUnit)라이브러리: 내
ApplicationContext: 스프링 컨테이너기존에는 AppConfig에서 직접 객체를 생성하고 DI를 했지만, 스프링 컨테이너를 통해 사용스프링 컨테이너는 @Configuration이 붙은 AppConfig 설정정보 사용@Bean이 붙은 메서드를 모두 호출해서
애노테이션 기반 자바 코드 설정 사용new AnnotationConfigApplicationContext(AppConfig.class)XML 설정 사용최근에는 스프링 부트를 많이 사용하면서 XML기반의 설정은 잘 사용하지 않는 편GenericXmlApplicationC

1\. Web ServerHttp 기반으로 동작정적 리소스 제공: 정적 html, css, js, 이미지, 영상ex) nginx, apache2\. WAS(Web Application Server)Http 기반으로 동작웹서버 기능 포함(정적 리소스 제공도 가능)프로그램

1\. 개념request를 관리/처리하고 response를 다시 내보내주는 자바 클래스의 일종서블릿 컨테이너라고 불리는 자바 어플리케이션을 통해 작동서블릿 컨테이너: 서블릿을 관리해주는 컨테이너, (ex)Tomcathttps://www.baeldung.com/

1\. 쓰레드란?애플리케이션 코드를 하나씩 순차적으로 실행한번에 하나의 코드 라인만 수행동시 처리가 필요하다면? 쓰레드 추가 생성2\. 요청에 따른 쓰레드 사용 예시1) 단일 요청: 쓰레드 하나 사용요청 > 연결 > 쓰레드 할당 > servlet 호출 > 응답 > 쓰레

1\. 개념ApplicationContext : 스프링 컨테이너라고 부름(인터페이스)어노테이션 기반의 자바 설정 클래스로 만들 수 있음new AnnotationConfigApplicationContext(AppConfig.class) : ApplicationContex

스프링 내부에서 사용하는 빈과 내가 직접 등록한 빈을 getRole()로 구분 가능직접 등록한 애플리케이션 빈 조회 결과
스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법ac.getBean(빈이름, 타입)ac.getBean(타입)
타입으로만 조회할 경우 동일 타입의 스프링 빈이 둘 이상 존재하면 오류 발생빈 이름을 지정하여 조회하거나,ac.getBeansOfType()을 통해 해당 타입의 모든 빈 조회
부모타입으로 조회시 자식타입도 함께 조회됨때문에 Object 타입으로 조회하면 모든 스프링 빈이 조회됨
1\. 웹 애플리케이션과 싱글톤웹 애플리케이션은 보통 여러 고객의 동시요청이 발생함때문에 요청시마다 새로운 객체 생성을 하는 것은 불가능=> 해당 객체를 하나만 생성하여 공유하도록 설계 (싱글톤 패턴)}// new SingletonService(); 컴파일
1\. 스프링빈의 싱글톤 보장스프링 컨테이너는 싱글톤 레지스트리이므로, 스프링빈의 싱글톤을 보장해야 함자바 코드에서 여러번 호출될 경우, 자체 라이브러리를 사용하여 싱글톤을 유지출력된 클래스 정보에 'CGLIB' 가 추가되어 있음2\. 동작원리@Configuration

스프링빈을 등록하기 위해서 @Bean(자바코드), (XML) 등을 통해 설정정보에 등록하고싶은 스프링빈을 직접 코드로 작성하는 것 외에 다른 방법은 없을까? \-> 스프링은 자동으로 스프링빈을 등록하는 컴포넌트 스캔 기능을 제공
의존관계를 주입하는 방법은 크게 4가지가 있으며, 각각 아래와 같은 특징이 있음생성자 주입가장 흔하게 사용하는 방법특징호출시점에 딱 1번만 호출되는 것이 보장됨따라서 "불변, 필수" 의존관계에서 사용수정자 주입(Setter)필드의 값을 변경하는 수정자 메소드를 통해 의
생성자 주입 방식을 권장하는 이유?의존관계 주입은 주로 한 번 하게되면 변경할 일이 없음 -> 즉, 불변수정자 주입방식(과거에 주로 썼던)의 경우, public 으로 setXXX 메소드를 열어두게 되므로 변경가능성이 높음또한, 순수 자바코드로 단위 테스트코드를 짜는 경
Lombok의 @RequiredArgsConstructorfinal이 붙은 필드를 모아서 생성자를 자동으로 만들어줌(@Autowired 부분 작성할 필요가 없음)최근 트렌드는,생성자를 하나만 두고 @Autowired는 생략하고 Lombok 라이브러리의 @Required
@Autowired는 기본적으로 타입으로 조회하지만, 타입이 동일해서 선택된 빈이 2개 이상인 경우 문제 발생위와 같이 DiscountPolicy가 있고, 하위 타입인 FixDiscountPolicy, RateDiscountPolicy가 모두 의존관계 자동주입이 실행되