스프링은 2.7.17 버전사용
java 11
intelJ
객체 지향에 대해 항상 생각하면서 코딩해야한다. SOLID
역할과 구현을 충실하게 분리한다.
다형성도 활용하고, 인터페이스와 구현 객체를 분리한다.
DIP 의존 관계 역전 원칙
- 클라이언트 코드에 구체화 구현 클래스가 존재하였다. > Appconfig가 의존관계를 주입하였다.
OCP 확장에는 열려있으나 변경에는 닫혀있어야 한다.
- app config에서 변경을 했지 사용 영역의 변경을 하지 않았다.
SRP 단일 책임 원칙 - 한 클래스는 하나의 책임만 가져야 한다.
- 구현 객체를 생성하고 연결하는 책임은 Appconfig가 담당
- 클라이언트 객체는 실행하는 책임만 담당
alt + insert = 만능
psvm = public static void main
soutv = System.out.println("order = " + order);
test 항상 중요하다.
final엔 항상 값이 들어와야 한다.
그래서 지우고 인터페이스에만 의존하도록 만들면 널포인트 익셉션이 난다.
생성자를 주입해줘야 한다.
구성 영역 = 기획자(config)이 부분만 계속 바뀌고 나머지(사용 영역)는 바뀔 일이 없다.
프레임 워크
junit (test)
제어권이 나한테 없음
라이브러리
제어권이 나한테 있어서 내가 호출한다.
di 컨테이너
객체를 생성하고 관리하며 의존관계를 연결, 어샘블러, 오브젝트 팩토리 등으로 불리기도 한다.
스프링화
스프링 컨테이너는 @Configuration이 붙어야 되고, @Bean이 붙은 모든 메소드를 호출한다.
config에서 직접 찾는게 아니라 스프링 빈에서 찾는다.
이 것의 장점은 ?
나중에 알려준디
객체 지향은 뭔가 수정하는 것엔 편리하지만 스위치가 점점 늘어나서 그것에 대한 로직을 잘 짜야할 것 같다.