반응형
강의후기
스프링 핵심 원리 - 기본편 후기
스프링 명강의인데 구입한지는 꽤 됐지만 늦게 수강하게 되었고 정리는 더 늦어지게 되었다...😅 어려웠던 개념들, 모르고넘어갔던 부분, 스프링의 원리에 대해 배울 수 있었고 고민해볼 수 있었던 좋은 시간이었다! 아직 완벽하게 이해했다고하기는 매우 어려우나 평생소장할 수 있는 강의 이니 커리큘럼을 한바퀴 돌아보고 다시 들어보면 좋을 것 같다. 그때게는 또 다른 시야에서 볼 수 있지 않을까싶다.
1. 새로알게된 내용 및 개념 정리
좋은 객체지향 설계의 5가지 원칙(SOLID)
- SRP : 단일책임 원칙(Single Responseibility Principle)
- 하나의 클래스는 하나의 책임만 가짐 -> 책임의 기준은 변경
- OCP : 개방-폐쇄 원칙(Open/Closed Principle)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 함 -> 다형성 활용
- 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
- 문제점 : 구현 객체를 변경하려면 클라이언트 코드 변경 -> 다형성을 사용했지만 OCP원칙을 지킬 수 없음
- 해결 : 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자 필요 -> 스프링컨테이너
- LSP : 리스코프 치환 원칙(Liskov Subsitution Principle)
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야한다함 -> 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야한다는 것
- ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위한, 느리더라도 앞으로 가야함(컴파일 성공과는 별개의 문제)
- ISP : 인터페이스 분리 원칙(Interface segregaion Principle)
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
- ex) 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
- ex) 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
- 분리하면 정비 인터페이스가 변해도 운전자 클라이언트에 영향 X -> 인터페이스가 명확해지고, 대체 가능성이 높아짐
- DIP : 의존관계 역전 원칙(Dependency Inversion Principle)
- 구현클래에스 의존하지 말고, 인터페이스에 의존 -> 역할에 의존! 구현체에 의존하게 되면 변경이 어려워짐
IoC, DI, 컨테이너
- IoC : 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는것(제어권을 넘기는 것)
- AppConfig가 등장 한 후 구현객체는 자신의 로직을 실행하는 역할만 담당. 프로그램의 제어 흐름은 AppConfig에게.
- ex) 'OrderServiceImpl'은 필요한 인터페이스들을 호출하지만 어떤 구현객체들이 실행될지모름. 심지어 'OrderServiceImpl'도 AppConfig가 생성. AppConfig는 'OrderServiceImpl'이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할 수 있음. 그런사실도 모른체 'OrderServiceImpl'은 묵묵히 자신의 로직을 실행
- 프레임워크 vs 라이브러리 -> 제어의 역전 여부
- 프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크(JUnit) -> 제어권이 나에게 없음. JUnit에게
- 반면 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 라이브러리
- DI(의존관계 주입)
- 'OrderServiceImpl'은 'DiscountPolicy' 인터페이스에 의존. 실제 어떤 구현객체가 사용될지 모름
- 의존관계는 정적인 클래스 의존 관계와 실행시점에 결정되는 동적인 객체(인스턴스) 의존관계를 분리해서 생각해야 함
- 정적인 클래스 의존관계 : 클래스의 import코드만 보고 의존관계 쉽게 판단. 애플리케이션을 실행하지 않아도 분석 가능 -> But 이러한 클래스 의존관계만으로는 실제 어떤 객체가 'OrderServiceImpl'에 주입될지 알 수 없음
- 동적인 객체 인스턴스 의존관계 : 애플리케이션 실제 시점(런타임)에 실제 구현 객체 인스턴스를 생성하고 클라이언트에 그 참조값을 전달해 클라이언트와 서버의 실제 의존관계가 되는것 -> 의존관계 주입
- 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스 변경 가능
- 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경
- IoC 컨테이너, DI 컨테이너 : 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것(AppConfig)
- 의존관계 주입 초첨에 맞추어 최근에는 DI컨테이너라 불림 또는 어샘블러, 오프젝트팩토리 등으로 불리기도...
스프링컨테이너
- 스프링 컨테이너 : 'ApplicationContext'
- 스프링 컨테이너는 @Configuration이 붙은 'AppConfig'를 설정 정보로 사용
- @Bean이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링컨테이너에 등록 -> 스프링빈
싱글톤패턴 -> 싱글톤 컨테이너(스프링)
- 싱글톤패턴 : 클래스의 인스턴스가 1개만 생성되는 것을 보장하는 디자인패턴
- 객체 인스턴스를 2개이상 생성하지 못하도록 함 -> 생성자를 private으로 막아 외부에서 new 키워드로 객체인스턴스가 생성되는 것을 막음
- 단점이 많음 : 코드가 많이들어간다, 테스트하기 어렵다, 유연성이 떨어진다 등등 -> 싱글톤컨테이가 해결
- 싱글톤컨테이너 : 스프링컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스 싱글톤으로 관리
- 스프링빈 -> 싱글톤으로 관리되는 빈
- 스프링컨테이너는 싱글턴 패턴을 적용하지 않아도 객체인스턴스를 싱글톤으로 관리
- 주의점 : 무상태로 설계해야함!
@Component
- @ComponentScan은 @Component가 붙은 모든클래스를 스프링빈으로 등록
- @Configuration에는 Component 포함되어 있음
- @Autowired -> 자동으로 의존관계 주입
- 프로젝트 최초 생성시 @SpringBootApplication에 Component가 포함되어 있어 자동으로 프로젝트 전체가 컴포넌트 스캔의 대상이 됨.
- 어노테이션에는 상속관계가 없음 -> 어노테이션이 특정 어노테이션을 들고 있는 것을 인식할 수 있는것은 스프링이 지원하는 기능
의존관계 주입법 4가지
- 생성자 주입
- 프레임워크에 의존하지 않고, 순수한 자바언어의 특징을 잘 살리는 방법!
- 생성자 호출 시점에 1번만 호출, 불변, 필수, 권장!!
- final 키워드 -> 생성자에 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에 막아줌, 생성자 주입방식에서만 사용
- 수정자 주입(Setter) : 선택, 변경 가능성이 있는 의존관계에 사용
- 필드 주입 : 필드에 바로 주입, 외부에서 변경이 불가능해 테스트하기 어려움, 사용X
- 일반 메서드 주입 : 한번에 여러필드 주입, 잘 사용하지 않음
@Autowired의 우선순위 -> @Primary, @Qualifier 활용
- @Primary : 메인커넥션빈과 서브커넥션빈이 있을 때 메인커넥션에 주로사용, 먼저 조회
- @Qualifier : 서브커넥션빈을 사용할때 @Qualifier("")을 지정하여 사용 -> 우선순위 상
2. 느낀 점
이 강의를 통해 몇번을 정리해도 이해가 잘 되지 않았던 IoC, DI, 컨테이너에 대해 이해가 되었다! 더불어 라이브러리와 프레임워크의 차이점에 대해서도 생각해볼 수 있었다. 또한 프로젝트 때도 사용해봤지만 잘 이해가 되지 않았던 @Configuration과 @Bean에 원리에 대해서도 알게 되었다. 지난 프로젝트를 되짚어 보던지 새로운 프로젝트를 시도해보면서 전반적인 플로우를 탐색해봐야겠다.
강의의 커리큘럼 중 빈 생명주기 콜백과 빈스코프에 대해는 정리하지 않았는데 사실 이부분은 2번씩 들어도 잘 이하가 되지 않아 조금 더 시간을 들여야 할것 같다😭
로직이 돌아가는 지 확인하는 정도의 테스트 코드가 아니라 스프링부트전반에 대한 테스트코드를 작성하는것을 보면서 강사님의 지식의 깊이를 느낄 수 있었다. 나도 조금 더 욕심내서 공부하도록해야겠다👍
반응형
'기록 > 강의' 카테고리의 다른 글
| [강의 후기] 인프런 스프링입문강의 후기 / 김영한 (0) | 2021.12.25 |
|---|
