Spring(스프링) - 객체지향 적용 및 스프링 기본
(interface) interface = new (구현 obj)
인터페이스를 통해 객체를 생성한 곳에서 객체 생성 부분만 변경 해 주면 쉽게 서비스 변경이 가능
=> 문제점 : 클라이언트의 코드를 수정해야 함
DIP : 인터페이스에 의존을 하고 있지만 동시에 객체를 생성하기 때문에 구현 클래스에도 의존하고 있음 <위반>
OCP : 구현 클래스를 교체 해야 하는 순간 의존하는 클라이언트의 소스를 변경 해야 함 <위반>
=> 해결하기 위해서는 인터페이스에만 의존 하도록 해야함. 즉, 누군가 구현 클래스를 대신 생성해서 사용하는 클래스의 인터페이스에 주입 해주어야 함
관심사의 분리
인터페이스의 역할을 인터페이스가 정하는 것이 아닌 애플리케이션 단위에서 정해야 함
=> AppConfig 사용
AppConfig는 구현 객체를 생성하고 연결해주는 역할을 수행
AppConfig에서 구현 객체를 생성하면서 생성자를 통해 사용할 서비스를 주입을 해주어야 함
구현객체에는 인터페이스만 존재
구현 객체 입장에서는 사용할 인터페이스만 알고 주입을 받아 사용만 함
AppConfig를 사용할 땐 역할 과 구현이 구분 될 수 있게 작성 해야 함
사용영역과 구성영역이 나누어 짐(SRP 원칙)
=> 변경이 필요할 땐 구성영역만 변경하면 됨
객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입(DIP 원칙)
객체 인스턴스가 변경해도 클라이언트를 수정할 필요가 없음(OCP 원칙)
#테스트
@BeforeEach
테스트를 실행하기 전 무조건 실행 (함수로 구현한 후 어노테이션 사용)
테스트가 여러개면 여러번 실행
스프링의 기본
#IoC(Inversion of Control) 제어의 역전
프로그램의 제어 흐름을 직접 제어하는 것이 아닌 외부에서 관리하는 것
ex) 어떤 구현 객체를 사용할지는 AppConfig에서 결정
프레임워크 vs 라이브러리
프레임워크가 내가 작성한 코드를 제어하고 대신 실행하면 프레임워크
내가 작성한 코드가 직접 제어의 흐름을 담당하면 라이브러리
#DI(Dependency Injection) 의존관계 주입
정적인 클래스 의존 관계와 실행 시점에 결정되는 동적인 객체 의존 관계 둘을 분리해야함
정적인 클래스 의존 관계
: 클래스가 사용하는 import코드만 보고 의존관계를 쉽게 판단할 수 있음(실행하지 않아도 판단 가능)
동적인 인스턴스 의존 관계
실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계
실행시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존 관계가 연결 되는 것을 "의존관계 주입" 이라 함
=> 클라이언트 코드를 변경하지 않고 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있음
=> 정적인 클래스 의존관계를 변경하지 않고 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있음
IoC 컨테이너, DI 컨테이너
컨테이너 : AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는것
@Configuration을 사용하여 Spring에서 직접 설정 정보를 관리 함
@Bean을 사용하여 Spring 컨테이너에 등록을 시킴
ApplicationContext를 스프링 컨테이너라고 함
=> 스프링 컨테이너에서 Bean들을 관리 함
=> 직접 가져오는 것이 아닌 스프링 컨테이너를 통해서 Bean객체를 가져와서 사용
=> @Bean 붙은 Bean 객체를 모두 호출하여 생성
=> 메서드의 이름을 Bean 객체 이름으로 사용