Backend - Java Spring97 [SpringCore 핵심원리] 생성자주입과 롬복 1. 불변 - 대부분의 의존관계 주입은 한번 일어나면 앱 종료시점까지 의존관계를 변경할 일이 없다. (불변해야하는 경우가 많다.) - 수정자는 settter를 public으로 열어두어야 하기 때문에 위험하다. - 테스트코드할때 의존성 주입을 넣어야하는 파라미터를 알려줌(컴파일 오류 단에서 해결 가능) - final을 넣을 수 있다. - 누락을 막는데에 컴파일러의 도움이 가능하다. - 생성자주입을 쓰되, 가끔 옵션이 필요하면 수정자 주입을 사용하면 된다. 2. Lombok - @ToString, @Getter, @Setter, - @RequiredArgsConstructor :(권장) 생성자 주입에서 쓰면됨. final이 붙은 필드만을 모아서 생성자를 자동으로 만들어준다. - @AllArgsConstruc.. 2024. 2. 17. [SpringCore 핵심원리] 다양한 DI 방법 1. 의존관계 자동 주입 - 4가지가 있다 : 생성자 주입 : 수정자 주입(setter 주입) : 필드 주입 : 일반 메서드 주입 2. 생성자 주입 - 특징 : 생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다. - 불변성, 필수 의존관계에서 사용된다. (memberRepository, discountPolicy가 안바뀌게 함, final 붙이는 것도) - 근데! 생성자가 딱 한개만 있으면 @Autowired 를 생략해도 된다. (두개일땐 안됨, 스프링 빈이어야 한다.) - 생성자주입은 빈을 등록하면서 주입이 같이 일어난다. 3. 수정자 주입 - final 빼고 set~로 네이밍을 한 setter를 만든다. - 의존관계 주입 두번째 단계에서 일어남. 좀 늦나보다 - 선택/변경 가능성이 있는 의존관계에.. 2024. 2. 17. [SpringCore 핵심원리] 컴포넌트스캔 1. 컴포넌트스캔과 의존관계 자동 주입 - 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트스캔 기능을 제공한다. - @ComponentScan 은 @Component가 붙은 애들을 자동으로 빈에 등록한다. - @Component 애너테이션을 이제 붙여주면 스프링 빈에 자동으로 등록된다. - 그럼 DI는 어떻게하나 ? 원래는 AppConfig에서 하나씩 의존관계를 주입해주었지만, 이제는 - 생성자 위에 @Autowired 기능을 이용하면 클래스의 인터페이스에 맞는 의존성을 알아서 주입해준다. (여러 의존관계도 한번에 된당) - 알아서 등록하는 스프링 빈의 기본 이름은 클래스명을 사용하면서, 카멜케이스로 변경 (직접 지정도 가능) - 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다. .. 2024. 2. 17. [SpringCore 핵심원리] @Configuration 1. @Configuration - 싱글톤을 위해서 존재하는 놈이다 - Appconfig에서 MemoryMemberRepository는 new 생성자로 두번 호출이 될 수 밖에 없는데 - 테스트를 해보면, - @Configuration 이 붙으면 바이트코드 라이브러리를 사용해서 다른 클래스를 만들어서 조작한 그 놈을 스프링 빈으로 등록한다. - 스프링 빈이 있으면 그대로 반환, 없으면 생성해서 등록하는 로직이 있을 것이다. 어쨌든 싱글톤을 만족하게 해준다. - @Bean 만 적용하면 @Configuration 이 적용이 안된다. 스프링 빈은 등록이 되지만, 여러번 중복 호출한다. (싱글톤 깨진다) - 설정파일에는 무조건 넣으세요 2024. 2. 17. [SpringCore 핵심원리] 빈 설정과 싱글톤 1. 스프링 빈 설정 메타정보 : BeanDefinition - XML 이던, 뭐든간에 결국 BeanDefinition을 만들어버리면 스프링컨테이너는 이거만 알면 된다. - 즉, 스프링컨테이너는 BeanDefinition 에만 의존한다. (BeanDefinition 추상화에만 의존하도록 설계한거당) - 직접 스프링컨테이너에 등록할 수도 있다. 하지만 실무에선 안씀 2. 웹앱과 Singleton - 고객요청이 많은 웹앱에서 순수Java로된 DI컨테이너를 만들게되면 객체를 미친듯이 많이 생성하게 됨(메모리 낭비) - 해당 객체가 1개만 생성되고, 공유하도록 설계하면 된다. (싱글톤) - 싱글톤은 클래스 인스턴스가 딱 1개만 생성되도록 보장하는 패턴이다. - private 생성자를 이용해서 외부에서 임의로 n.. 2024. 2. 17. [SpringCore 핵심원리] IoC, DI, Container 1. IoC(제어의 역전) - 프로그램흐름의 제어를 구현객체가 아닌 외부에서 담당한다. - AppConfig에서 @Configuration 애너테이션 밑에 @Bean 애너테이션을 달면 스프링Bean으로 등록이 가능하다. - 아래처럼 ApplicationContext를 이용하면 스프링컨테이너에 빈으로 등록이 가능하다 - ApplicationContext 는 스프링컨테이너다. (인터페이스다) - 스프링컨테이너는 @Configuration이 붙은 애를 설정(구성) 정보로 사용한다. @Bean이라 적인 메서드를 모두 호출해서 반환된 객체를 스프링컨테이너에 스프링빈으로 등록한다. - @Bean 이름이 붙은 메서드의 이름을 사용한다(변경 가능하긴함) - applicationContext.getBean()으로 스프링.. 2024. 2. 17. [SpringCore 핵심원리] Config 1. OrderApp 실행 보면서 역할과 책임의 분리 확인하기 - MemberService에서는 Member관리 - OrderService에서는 Order관리를 해야지 - OrderService에서 할인 관련한건 createOrder할 때 할인정책을 정하는 객체한테 가서 해달라고 하면 됨 2. 만약 할인정책을 업데이트하게되면 ? - DiscountPolicy Interface의 구현체를 바꾸면 되는군! - DiscountPolicy의 구현체 생성 - 근데 할인정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야한다(OCP 위반) - 클라이언트가 직접 구현체의 선택까지 해야하는가 ? - 실제 클라이언트는 구현체 또한 의존을 하고있다!(DIP 위반) - 이러면 안되는딩! 3. 해결 방안.. 2024. 2. 16. [SpringCore 핵심원리] 설계 1. 비즈니스 요구사항 - 회원 : 회원을 가입하고 조회할 수 있따. : 회원에는 일반과 VIP 두가지 등급이 있다. : 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다(TBD) - 주문과 할인 정책 : 회원은 상품을 주문할 수 있다. : 회원 등급에 따라 할인 정책을 적용할 수 있다. : VIP는 1000원 할인해주는 고정 금액 할인을 적용(TBD) : 할인정책은 변경 가능성이 높다. 2. 설계 - 회원 도메인 : 클라이언트 -> 회원서비스 -> 회원저장소(interface) - 인터페이스 설계가 핵심 - Service에서 MemberRepository memberRepository = new MemoryMemberRepository(); - new ~ 부분이 DIP 위반이다.. 2024. 2. 16. 이전 1 2 3 4 5 ··· 13 다음
