스프링 핵심 원리

김영한님의 스프링 핵심 원리 강의 학습 내용입니다.하나의 클래스는 하나의 책임만 가져야 한다.변경 시 파급 효과가 적으면 잘 따른 것이다.소프트웨어 요소는 확장에 열려 있고 변경에 닫혀 있어야 한다.다형성을 활용한다.인터페이스를 구현한 새 클래스를 만들어 새 기능을 구

김영한님의 스프링 핵심 원리 강의 학습 내용입니다.HashMap은 동시성 이슈 발생 가능성이 있다. 이 경우 ConcurrentHashMap을 사용해야 한다.인터페이스와 구현클래스 모두에 의존하고 있다. : DIP 위반RateDiscountPolicy로 바꾸는 순간 O

김영한님의 스프링 핵심 원리 강의 학습 내용입니다. 스프링으로 전환 > * @Configuration : 설정정보 @Bean : 스프링 컨테이너에 등록 AppConfig에 있는 (@Configuration이 붙은)설정정보를 가지고 (@Bean이 붙은)메서드를 모두

김영한님의 스프링 핵심 원리 강의 학습 내용입니다.순수한 DI 컨테이너(AppConfig)는 요청을 할 때 마다 객체를 새로 생성한다. -> 메모리 낭비가 심하다.클래스의 인스턴스가 단 1개만 생성getInstance() : 항상 같은 인스턴스 반환isEqualTo :

김영한님의 스프링 핵심 원리 강의 학습 내용입니다. 컴포넌트 스캔과 의존관계 자동 주입 > * @Configuration : @Component를 포함하고 있다. @ComponentScan : Component가 붙은 클래스를 스캔해 스프링 빈으로 등록 @Autow

김영한님의 스프링 핵심 원리 강의 학습 내용입니다.객체 생성 -> 의존관계 주입스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 스프링 종료스프링 전용 인터페이스초기화, 소멸 메서드 이름 변경 불가코드