TaeheeLog TaeheeLog

안녕하세요 이번 포스팅은 의존관계 자동 주입에 대해 알아보겠습니다 의존관계 주입은 크게 4가지 방법이 있습니다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 이름 그대로 생성자를 통해서 의존 관계를 주입받는 방법입니다. 지금까지 저희가 진행했던 방법이 바로 생성자 주입이죠 사실 위에 4가지 방법 중 생성자 주입이 가장 권장하는 주입 ㅂ아법입니다. 생성 자 주입의 특징으로는 - 생성자 호출싲머에 딱 1번만 호출되는 것이 보장됩니다. - 불변, 필수 의존관계에 사용합니다 여기서는 불편과 필수라는 키워드가 중요한데요, 의존관계를 주입하고 나서는 변경이 불가해야 한다는 것입니다. @Component public class OrderServiceImpl implements..

안녕하세요 이번 포스팅은 컴포넌트 스캔에 대해서 알아보겠습니다!!! 컴포넌트 스캔과 의존관계 자동 주입 시작하기 지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했습니다. 예제에서는 몇 개가 안되었지만, 이렇게 등록해야 할 스프링 빈이 수십, 수백 개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생합니다. 역시 개발자는 반복을 싫어합니다. (무엇보다 귀찮다 ㅠㅠ) 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공합니다. 또 의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공합니다. 코드로 컴포넌트 스캔과 의존관계 자동 주입을 알아봅시다. 먼저..

안녕하세요! 이번 포스팅은 싱글톤 컨테이너에 대해 알아보겠습니다! 웹 애플리케이션과 싱글톤 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했습니다. 대부분의 스프링 애플리캐이션은 웹 애플리케이션인데 웹이 아닌 애플리케이션 개발도 얼마든지 개발할 수 있습니다. 또한, 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 합니다. 가정 상황은 아래의 그림과 같습니다. 스프링 없는 순수한 DI 컨테이너 테스트 import hello.core.AppConfig; import hello.core.member.MemberService; import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test; import static org..

안녕하세요 이번 포스팅은 스프링 컨테이너를 XML로 설정하는 것을 알아보겠습니다. 스프링 컨테이너는 다양한 형식의 설정 정보를 받아들일 수 있게 유연하게 설계되어 있습니다. (자바 코드, XML, Groovy 등등) 지금 까지는 new AnnotationConfigApplicationContext(AppConfig.class) 이렇게 해서 자바 코드로 컨테이너를 생성했습니다. XML 설정 사용 최근에는 스프링 부트를 많이 사용하면서 XML 기반의 설정은 잘 사용하지 않습니다. 아직 많은 레거시 프로젝트 들이 XML로 되어있고 또 XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점도 있습니다. GenericXmlApplicationContext를 사용하면서 xml 설정 파일을 넘기면 됩니다..

안녕하세요 이번 포스팅은 지난 포스팅에 이어서 작성하겠습니다. IoC(Inversion Of Control) 제어의 역전 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 new로 생성하고 연결하고 실행했습니다. 한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했습니다. 개발자 입장에서는 자연스러운 흐름이죠. 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당합니다. 프로그램의 제어 흐름은 이제 AppConfig가 가져가게 되는 것이죠. 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모릅니다. 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있고 심지어 ..

안녕하세요! 이번 포스팅은 지난 포스팅에 이어서 작성해보도록 하겠습니다. 우선 기존의 정액 할인 정책을 정률 할인 정책으로 변경하면서 발생하는 문제점을 알아보고 대안을 살펴보겠습니다. 현재 가정하고 있는 상황은 정액 할인으로 서비스를 하고 있는데 정률 할인으로 변경하려고 합니다. 그렇다면 정률할인 클래스도 만들어줘야겠죠? 다음과 같이 만들어 줍니다. import hello.core.member.Grade; import hello.core.member.Member; public class RateDiscountPolicy implements DiscountPolicy { private int discountPercent = 10; //10% 할인 @Override public int discount(Mem..

안녕하세요 이번 포스팅은 DI 컨테이너를 활용해서 OCP와 DIP를 준수하면 개발하는 예제와 JUnit 사용에 대해서 알아보겠습니다!! 회원에 관한 인터페이스와 클래스는 위와 같이 생성해보겠습니다. 우선 MemberRepository는 회원가입과, 조회의 기능을 갖고 있는 인터페이스이며 인터페이스를 구현하는 클래스는 MemoryMemberRepository와 DBMemberRepository 이렇게 2개가 있다고 가정합니다. MemoryMemberRepo는 Member 객체를 생성해서 HashMap에다가 저장하고 찾는 방식이고 DBMemberRepo는 말 그대로 DB에 저장하고 찾는 방식입니다. 우선 다음의 enum과 클래스들을 생성해보겠습니다. //회원등급 public enum Grade { BASIC..

안녕하세요 이번 포스팅은 그 유명한 SOLID 원칙에 대해서 알아보겠습니다!! SOLID 원칙 SOLID는 클린 코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리한 것으로 다음과 같습니다. • SRP: 단일 책임 원칙(single responsibility principle) • OCP: 개방-폐쇄 원칙 (Open/closed principle) • LSP: 리스코프 치환 원칙 (Liskov substitution principle) • ISP: 인터페이스 분리 원칙 (Interface segregation principle) • DIP: 의존관계 역전 원칙 (Dependency inversion principle) 5가지 원칙 중에서 중요도를 나눠서 비교해 봤을 때 OCP와 DIP..