| 내 티스토리가... 카카오 일해라 |
티스토리에 작성할 수가 없어서 대피왔다.
1. 프레임 워크란?
프레임 워크란, 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을
재사용이 가능하게끔 일련의 협업화된 형태로 클래스를 제공하는 것프레임워크 vs 라이브러리
라이브러리란 자주 사용되는 로직을 재사용하기 편리하도록 잘 정리한 일련의 코드들의 집합을 의미한다.쉽게 생각해서
프레임워크 : 자동차의 프레임
라이브러리 : 자동차의 기능을 하는 부분
프레임 워크의 장점
- 효율적
- 퀄리티 향상
- 유지 보수 Good.
프레임 워크의 단점
- 러닝 커브
- 제작자의 의도 파악
- 프레임 워크 의존
Spring
Spring
자바 + 코틀린 언어 프레임워크
자바는 객체지향 언어
스프링 -> 객체지향의 특징
다형성
인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 가능
다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작
클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.
스프링 다형성 특징 정리
- 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져오기 가능
- 유연하고, 변경이 용이
- 확장 가능한 설계
- 클라이언트에 영향을 주지않는 변경 가능
- 인터페이스를 안정적으로 잘 설계하는 것이 중요
Spring
- 다형성이 가장 중요하다.
- 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.
- IOC(제어의 역정),DI(의존성 주입)은 다형성을 활용해서 역할과 구현을
편리하게 다룰 수 있도록 지원하는 것이다. - 레고 블록을 조립하듯 구현을 편리하게 해주는 것이 스프링이다.
IOC(제어의 역전)
코드나 객체의 호출 작업을 개발자가 결정하는 것이 아니라 외부에서 결정하는 것더욱 쉽게 말하면 대신해준다(Inversion Of Control)는 뜻
Spring Bean
자바
객체 변수명 = new 객체(); -> 생성자를 통해 직접 할당 및 생성
Spring Bean
스프링 컨테이너에 의해 관리되는 객체 IOC,DI, etc...
Spring Container
프로그래머가 작성한 코드의 처리 과정을 위임받아 독립적으로 처리하는 존재컨테이너의 사전적 의미는 무언가를 담는 용기
즉, 컨테이너는 객체관리를 주로 수핼하는 용기 정도로 이해 가능
Why Spring Container??
자바 객체를 사용하기 위해서는 new 생성자 - Setter, Getter 사용
객체가 무수히 많으면 의존성 UP, 결합도 Down
OOP에 대한 위반
-> 의존성 제어, 즉 객체 간의 의존성을 낮추기 위해 스프링 컨테이너 사용
Bean Factory VS ApplicationContext
BeanFactory
Bean 객체를 생성하고 관리하는 인터페이스
컨테이너 구동 시 생성 X
Lazy Init
ApplicationContext
BeanFactory를 상속받은 Interface + 부가적인 기능
컨테이너 구동 시 생성 Bean 객체 스캔 후 객체화
Eager Init
- 추가 기능 - 국제화 지원 택스트 메세지, 이미지 파일 로드 기능, 빈 이벤트 통보 기능
Bean 등록하는 법
@Bean
개발자가 컨트롤 불가능한 주로 외부 라이브러리들에 사용
매서드에 사용
@Component
개발자가 직접 컨트롤 가능한 경우 사용
클래스에 사용
- 그럼 개발자가 생성한 클래스에 @Bean 선언이 가능할까?
Bean LifeCycle
스프링 IOC 컨테이너가 빈 관리 -> 의존관계 주입
DI(의존성 주입) -> 3가지 방법
1. 필드 주입
- @Autowired 사용
- 사용이 너무 편함
- SRP 위반 -> 너무 많은 의존성을 가짐 -> 의존성이 눈에 보이지 않음 -> 빈 구현을 하나하나 전부 뜯어봐야함 -> 테스트할 때 new로 생성해줘야함
- final 선언 불가 -> 새로 할당하는 시점이 있을 수 있음
- DI(스프링) 컨테이너와 강한 결합
2. 세터(Setter) 주입
- @Autowired 사용
- final 선언 불가
- OCP 위반 -> 언제든지 변경될 수 있음 -> 상황에 따라서 이점이 아예 없을 수 있다.
3. 생성자(Constructor) 주입
- @Autowired 생략 가능
- final 사용 가능 -> 불변성 보장
- 테스트 용이함
- 롬복이라는 라이브러리와 결합이 좋음
- 순환 참조를 막을 수 있음
Bean LifeCycle 의존관계 주입 단계
생성자 주입
객체 생성과 의존성 주입이 동시에 일어남
세터, 필드 주입
객체 생성 후 의존성 주입이 일어남
생성자 주입 이점
- null을 주입하지 않는 한 NullPointerException은 발생하지 않는다.
- 의존관계를 주입하지 않은 경우 객체를 생성할 수 업다, 즉, 의존관계에 대한 내용을 외부로 노출시킴으로서 컴파일 타임에 오류를 잡아낼 수 있다.
Bean LifeCycle
스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입
-> 초기화 콜백 메서드 호출 -> 사용 -> 소멸 전 콜백 메서드 호출
-> 스프링 종료Bean LifeCycle 설계 팁
객체의 생성과 초기화를 분리하자
생성자는 파라미터를 받고 메모리 할당을 책임.
초기화는 생성된 값을 외부 커넥션에 연결하는 책임 -> 무거움
따라서, 생성자 안에서 무거운 작업을 하지 말자
명확하게 나눠야 유지 보수 관점에서 좋다.
Bean LifeCycle 생명주기 콜백 관리
- 인터페이스(InitializingBean, DisposableBean)
- 설정 정보에 초기화 메서드, 종료 메서드 지원
- @PostConstruct, @PreDestroy 어노테이션 지원
@PostConstruct, @PreDestroy 어노테이션
- 스프링 권장 방식
- 어노테이션으록 간편함
- 컴포넌트스캔과 잘 어울림
