그날그날 공부기록

롬복을 사용하면 생성자나 getter, setter 같은 메서드를 자동으로 작성해준다! 프로젝트를 생성할 때 롬복을 적용했다면 바로 사용 가능하지만 그렇지 않을 경우 직접 추가해야 한다. 롬복 적용하기 build.gradle에 롬복을 추가해 준다. 제일 바깥쪽에 롬복 설정 코드를 추가한다. configurations { compileOnly { extendsFrom annotationProcessor } } dependencies 안에 롬복 라이브러리를 추가한다. dependencies { ... //lombok 라이브러리 추가 시작 compileOnly 'org.projectlombok:lombok' annotationProcessor 'org.projectlombok:lombok' testCompil..

의존관계 주입 방법에 대한 강의를 들으며 여러 방식이 있다는 것을 알았다. 하지만 최근에는 스프링을 포함하여 대부분의 DI프레임워크들이 생성자 주입 방식을 권장한다고 한다. 불변 대부분의 의존관계는 한번 일어나면 애플리케이션 종료 전까지 변하지 않아야 한다. setter 주입을 사용하면 그 메서드를 public으로 열어두어야 한다. → 실수할 가능성이 높아진다. → 생성자 주입은 객체 생성 시점에 한 번만 호출되기 때문에 불변하게 설계할 수 있다. 누락 스프링 프레임워크 없이 순수한 자바 코드로 실행시킬 경우 @Autowired는 동작하지 않는다. → 스프링 없이 순수한 자바로 테스트하는 경우가 많이 생긴다고 한다. 생성자 주입 방식이라면 컴파일 오류가 발생해 의존관계 주입에 관한 ‘누락'을 빠르게 알아..

@Autowired만 사용하면 필요한 스프링 빈이 없을 때 에러가 발생한다. 이유는 required 옵션의 기본값이 true이기 때문이다. 수정자 주입 등 스프링 빈이 없어도 코드가 동작해야 할 경우가 있으므로 알아두면 나중에 편할 것 같다! 아래 코드에 나오는 Member는 스프링 빈이 아닌 순수한 자바 클래스이다. 1. 우선 required 옵션값을 false로 설정해주면 된다. @Autowired(required = false) public void setNoBean1(Member noBean1) { System.out.println("noBean1 = " + noBean1); } 이렇게 설정 해주면 스프링 빈이 없을 경우 해당 메서드 자체가 실행되지 않는다. 2. null이 될 수 있는 부분에 @..

스프링의 의존관계 주입 방법 의존관계는 다양한 방식으로 주입받을 수 있다. 생성자 주입 setter(수정자) 주입 필드 주입 일반 메서드 주입 생성자 주입 생성자를 통해 의존관계를 주입받는다. 생성자는 1번만 호출된다. → 의 givendragon.tistory.com 저번 글에 이어서 작성. 필드 주입 필드에 @Autowired를 붙여 주입한다. 코드가 간결해지지만 외부에서 변경이 불가하다. → 테스트하기 힘들다. 스프링(DI 프레임워크)이 없다면 작동하지 않는다. 이러한 이유들 때문에 기피되는 방식이라고 한다. 왠만하면 사용하지 말자. (스프링 설정을 목적으로 하는 파일에서는 사용되기도 함) @Component public class OrderServiceImpl implements OrderServ..

의존관계는 다양한 방식으로 주입받을 수 있다. 생성자 주입 setter(수정자) 주입 필드 주입 일반 메서드 주입 생성자 주입 생성자를 통해 의존관계를 주입받는다. 생성자는 1번만 호출된다. → 의존관계를 1번만 주입받는 것이 보장된다. 때문에 불변, 필수 의존관계에 사용된다고 한다. @Component public class OrderServiceImpl implements OrderService{ private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; @Autowired public OrderServiceImpl(MemberRepository memberRepository, Discount..

@Configuration public class AppConfig { @Bean public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } @Bean public OrderService orderService(){ return new OrderServiceImpl(memberRepository(), discountPolicy()); } @Bean public MemberRepository memberRepository() { return new MemoryMemberRepository(); } @Bean public DiscountPolicy discountPolicy(){ return new FixD..

@Configuration public class AppConfig { @Bean public MemberService memberService(){ System.out.println("call AppConfig.memberService"); return new MemberServiceImpl(memberRepository()); } @Bean public OrderService orderService(){ System.out.println("call AppConfig.orderService"); return new OrderServiceImpl(memberRepository(), discountPolicy()); } @Bean public MemberRepository memberRepository()..

싱글톤 패턴을 사용하였거나 스프링의 싱글톤 컨테이너를 사용하는 것처럼 싱글톤 방식은 여러 클라이언트가 하나의 인스턴스를 공유하게 된다. 따라서 싱글톤 객체의 상태를 유지(stateful)하게 설계하면 안되고 무상태(stateless)로 설계해야 한다. 특정 클라이언트에 의존하는 필드가 있으면 안된다. 특정 클라이언트가 값을 변경하는 필드가 있으면 안 된다. 가능하다면 읽기만 가능해야 한다. 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다. os시간에 멀티 스레드 간 동시성 문제를 배워 이해가 편했다. public class StatefulService { private int price; // 상태를 유지하는 필드 public void order(Stri..