개발자되기 프로젝트

자동 등록을 선호 @Component면 끝남 자동 빈 등록은 사용해도 OCP, DIP 지킬 수 있다. - annotation 수정은 필요 할 수 도 ㅎ 언제 수동으로 등록하는게 좋음? 애플리케이션은 크게 두 종류로 나눌 수 있음. 업무 로직 빈 : cotroller, service, repository 모두 업무로직, 보통 비즈니스 요구사항 개발시 추가, 변경됨. - 업무 로직은 숫자도 많고...controller, service, repository처럼 패턴이 있음. - 이럴 경우 자동 기능을 적극 사용하자. - 문제 발생하면 명확하게 파악 가능. 기술 지원 빈 : 기술적인 문제, AOP 처리할때 사용. db연결, 공통 로그 처리..등등 - 수자 적고, 애플리케이션에 광범위하게 영향 미침. - 문제가 ..

가끔 해당 타입의 스프링 빈이 다~ 필요한 상황이 있다. 1. AllBeanTest @Autowired 통해 DiscountPolicy 타입에 해당하는 스프링 빈을 받고, 출력하는 service를 작성 설정 클래스는 AutoAppConfig와 DiscountService를 등록 어? DiscountService를,, 설정파일..로..? --> Component class로 등록임 Component scan에 의해 DiscountService도 스프링 빈으로 등록됨 Create a new AnnotationConfigApplicationContext, deriving bean definitions from the given component classes and automatically refreshing..

흠 근데 @Qualifier를 그냥 사용하면 문제가 있음 @Qualifier("mainDiscountPolicy")라고 지정했다 해보자. 타입 체크 어떻게함?????????? annotaion을 만들어서 해결할 수 있음. 1. annotaion 생성 우리가 만든 annotaion에 @Qualifier를 적용해 주자. 즉, 우리가 만든 annotaion을 사용하면 @Qualifier가 매칭이 된다. @Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE}) @Retention(RetentionPolicy.RUNTIME) @Inherited @Documen..

@Autowired는 타입으로 조회를 한다. 근데 스프링 컨테이너에 같은 타입의 빈이 여러 개 있으면..? 1. 같은 타입이 2개! DiscountPolicy의 구현체는 2개가 있다. RateDiscountPolicy @Component public class RateDiscountPolicy implements DiscountPolicy{​ FixDiscountPolicy @Component public class FixDiscountPolicy implements DiscountPolicy{​ 둘 다 @Component등록이 되면 어떻게 될까? 2. Test public class AutoAppConfigTest { @Test void basicScan(){ AnnotationConfigApplica..

lombok 개편함 대부분 의존관계는 불변이다. 따라서 생성자에 final 키워드 사용함 근데 생성자도 만들어야 하고,,, 대입하는 코드도 만들어야하고.. 여간 귀찮은게 아니다. 해줘! 1. build.gradle - dependencies 추가 implementation 'org.projectlombok:lombok:1.18.18' implementation 'org.projectlombok:lombok:1.18.18' compileOnly 'org.projectlombok:lombok' annotationProcessor 'org.projectlombok:lombok' testCompileOnly 'org.projectlombok:lombok' testAnnotationProcessor 'org.pr..

최근에는 대부분 생성자 주입을 권장해! 여러가지 이유가 있다. 1. 불변 대부분의 의존관계 주입은 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전 까지 변하면 안된다! 수정자 주입을 사용하면, setXXX를 public으로 열어둬야함. 누군가 변경할 수 도 있고,,, 변경하면 안되는 것을 열어두는 것 은 좋지않아.. 생성자 주입을 객체 생성할 때 딱! 1번만 호출됨! 이후에 호출될 일 없음!!! 따라서 불변하게 설계가 쌉가능 2. 누락 프레임 워크 없이 순수한 자바 코드를 단위 테스트 하는 경우에.... 코드만 보면 의존관계를 확인하기 어렵다. Setter 주입을 사용하면.. 코드를 직접 안까지 까보거나, 컴파일을 해야 확인이 가능하다. 하지만 생성자 주입을 사용하면 의존관계를 주입 ..

1. 주입할 스프링 빈이 없어도 동작해야 할 경우도 있다. 주입할 스프링 빈이 없어도 동작해야 할 경우도 있다. @Autowired(required = false)로 지정하는 경우, 자동 주입할 대상이 없으면 수정자 메서드 호출 안됨. @Nullable : 자동 주입할 대상이 없으면 null 입력됨. Optional : 자동 주입할 대상이 없으면 Optional.empty가 입력됨. public class AutowiredTest { @Test void AutowiredOption(){ ApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class); } static class TestBean{ @Autowired(require..

1. 의존관계 주입 방법 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 2. 생성자 주입. ???? : @Autowired가 있네? 컨테이너에서 같은 타입의 빈 꺼내옴. 집어넣음 특징 - 생성자 호출 시점에 딲 1번 만 호출되는 것이 보장됨. - 불변, 필수 의존관계에 사용--> set을 public으로 열어두면 안됨 (getter, setter 막만들면 안됨!) @Component public class OrderServiceImpl implements OrderService{ private final MemberRepository memberRepository; //private final DiscountPolicy discountPolicy = new RateDiscoun..