뚝딱코딩

지금까지 배운 스프링 빈은 스프링 컨테이너 시작과 함께 생성되어 스프링 컨테이너 종료까지 유지된다고 했습니다. 그 이유는 스프링 빈이 기본적으로 싱글톤 스코프로 생성이 되기 때문입니다. -스코프 = 빈이 존재할 수 있는 범위. 스프링이 지원하는 스코프는 1. 싱글톤 : 기본 스코프 , 스프링 컨테이너 '시작 ~종료'까지 유지되는 가장 넓은 범위의 스코프 2. 프로토 타입: 컨테이너가 프로토타입 빈의 생성, 의존관계 주입까지만 관여하고 더는 관여하지 않는 짧은 범위의 스코프 3.웹관련 스코프 -1)request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프. -2)session: 웹 세선이 생성되고 종료될 때 까지 유지되는 스코프. -3) application: 웹 서블릿 컨텍스트와 같은 범위로 유지되..

빈 생명주기에 대해서 알아보겠습니다. 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고 애플리 케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요합니다. package hello.core.lifecycle; public class NetworkClient { private String url; public NetworkClient(){ System.out.println("생성자 호출, url = " + url); connect(); call("초기화 연결 메시지"); } public void setUrl(String url) { this.url = url; } //서비스 시작시 호출 public void conne..

의존관계를 주입하는 방법에는 다양한 방법이 있습니다. 1. 생성자 주입 2. 수정자 주입(setter) 3. 필드 주입 4. 일반 메서드 주입 생성자 주입 말 그대로 생성자를 주입하는 방법입니다. 특징 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다 불변, 필수 의존관계에 사용된다 수정자 주입(setter) Setter라고 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입. 특징 선택,변경 가능성이 있는 의존관계에 사용 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법 생성자 주입과 다르게 따로따로 설정해주어야함. +@Autowired의 기본 동작은 "주입할 대상이 없으면 오류 발생"이므로, 주입할 대상이 없어도 동작하게 하려면 @Autowired(required=false..

저번 시간까지는 스프링 빈을 등록할 경우 @Bean 어노테이션을 통해서 설정 정보에 직접 등록을 했는데요. 실무에서는 등록해야할 @Bean이 수십, 수백개가 되면서 굉장히 귀찮아집니다. (누락문제도 추가) 그래서 설정 정보 없이도 자동으로 스프링 빈을 등록하는 '컴포넌트 스캔'이라는 기능이 있는데요. 컴포넌트 스캔 기능을 확인하기 위해 기존의 AppConfig를 내버려두고 , AutoAppConfig 파일을 새로 만들었습니다. (excludeFilters는 이전에 @Configuration이 붙은 AppConfig도 스캔되는 것을 방지하기 위해, 추가한 코드입니다.) 이 코드를 보면 설정 정보 파일인데도 @Bean 어노테이션이 하나도 없습니다. @ComponentScan 어노테이션이 붙으면 @Config..

Di 컨테이너까지 알아보았고, 스프링으로 전환하여 컨테이너를 스프링 빈 등록 및 컨테이너에 대해서 알아보았습니다. 애플리케이션이 실행되면 클라이언트가 요청할 때 마다 DI 컨테이너에서 객체가 생성됩니다. 하지만 그림처럼, 웹 애플리케이션은 소수가 이용하기보다는 다수의 클라이언트가 이용하기 때문에 만약 고객 트래픽이 초당 10000건이 나오면 초당 10000건의 객체가 생성되고 소멸된다. -> 메모리가 낭비가 너무 심하다. 테스트 결과의 노란 부분을 보면 memberService1과 memberService2의 주소가 다른 것을 알 수 있다. 때문에 만약, 한 번에 수만~수십만의 트래픽이 발생한다면 서버가 터져버리고 말 것이다. 그렇기 때문에 해결방안으로는 , 객체가 딱 1개만 생성되고, 생성된 객체를 공..

이전 시간에 ApplicationContext를 통해 스프링 컨테이너를 만들어 보았습니다. 다시 정리해 보자면 ApplicationContext는 인터페이스이고 XML 기반의 설정 클래스와 , 자바 기반의 설정 클래스를 만들 수 있다고 했습니다. 그 중 JAVA기반의 AnnotationCofigApplicationContext를 사용하였고 이는 ApplicationContext 인터페이스의 구현체입니다. 스프링 컨테이너는 `new AnnotationConfigApplicationContext(AppConfig.class)`를 통해서 생성됩니다. 스프링 컨테이너를 생성 할 때는 구성 정보를 지정해줘야하는데 위 코드에서 보면 알 수 있듯 AppConfig.class로 설정 그러면 스프링 컨테이너는 파라미터로..

지금까지는 순수한 자보 코드만을 사용해서 DI를 적용했는데, 이제는 스프링으로 전환하여 사용해보겠습니다. AppConfig에 설정을 구성한다는 뜻의 @Configuration을 붙여줍니다. 각 메서드에 @Bean을 붙여 스프링 컨테이너에 스프링 빈을 등록해줍니다, 스프링 빈이 무엇인지는 다음시간에 설명하겠습니다. 회원가입을 진행하는 main 클래스인 MemberApp에도 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); 를 붙여줍니다. (이때 AppConfig.class에는 @Configuration 어노테이션이 붙여있어야 합니다.) ApplicationContext는 스프링 프레임..

저번시간에 만든 공연기획자 (AppConfig) 파일을 조금 다듬고 구현체 조립과 , SOLID원칙을 다시 한 번 확인해봅시다. 그 전에 현재 프로젝트의 전체적인 그림은 이와 같습니다. 구현체는 인터페이스에만 잘 의존하고 있는 모습입니다. 현재 AppConfig 파일을 보면, MemoryMemberRepository가 중복되어있는 것을 확인할 수 있습니다. 어짜피 한 프로젝트에서는 Reposiotory 방식을 맞출 것이기 때문에 이 중복을 제거하면 유지보수가 더 편합니다. 이렇게 객체를 만들어 주입해서 사용하면 , 방법이나 정책을 바꿀 경우 한 곳에서만 코드를 수정해주면 됩니다. 즉 AppConfig를 보면 역할과 구현 클래스가 한눈에 들어옵니다. 그럼 이제 마지막으로, 할인 정책을 다시 바꿔보면서 잘 ..

이번에는 기존에 작성한 '정액 할인 정책'에서 -> '정률 할인 정책'을 적용하기 위해 '정률 할인 정책' 구현체를 작성하고, 지금까지 작성된 코드 중 SOLID 원칙에 위배되는 점을 찾아 고쳐보겠습니다. DiscountPolicy라는 인터페이스에 '정액 할인 정책' / '정률 할인 정책' 구현체를 만들어 놓고 적용되는 정책에 따라 조립하듯 끼워넣기만 하면 됩니다. RateDiscountPolicy discountPercent라는 할인율은 10%으로 정해두고 DiscountPolicy 인터페이스에서 선언한 메서드인 discount를 재정의하기 위해 Overide 어노테이션을 붙입니다. 이 역시도 VIP인 경우 10%할인 그 외 BASIC인 경우 할인 적용 X를 하기 위해 IF문을 작성해주고 discoun..

지난 시간에는 회원 / 회원 서비스에 대한 도메인 설계 및 구현을 스프링 기능을 제외하고 순수 자바코드로 진행했었는데, 이렇게 짠 코드에는 어떤 문제가 있는지 살펴보겠습니다. 어떠한 문제가 있는지 알아보기 위해서는 객체지향 SOLID 원칙에 대해서 먼저 알아봐야합니다. SOLID는 객체지향 프로그래밍에서 다섯 가지 설계 원칙을 나타냅니다. 이 원칙은 소프트웨어 설계의 유지보수성, 확장성, 가독성, 재사용성 등을 향상시키는데 목적을 두고 있습니다. 1. 단일 책임 원칙(SRP) - 클래스는 하나의 책임만 가져야 한다. 2.개방/폐쇄 원칙(OCP) - 소프트웨어 엔티티는 확장에는 열려있고, 변경에는 닫혀있어야 한다. -새로운 기능을 추가할 때 기존의 코드를 변경하지 않고 확장할 수 있어야 한다. 여기서 보면..