뚝딱코딩

빈 생명주기에 대해서 알아보겠습니다. 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고 애플리 케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요합니다. 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를 적용했는데, 이제는 스프링으로 전환하여 사용해보겠습니다. AppConfig에 설정을 구성한다는 뜻의 @Configuration을 붙여줍니다. 각 메서드에 @Bean을 붙여 스프링 컨테이너에 스프링 빈을 등록해줍니다, 스프링 빈이 무엇인지는 다음시간에 설명하겠습니다. 회원가입을 진행하는 main 클래스인 MemberApp에도 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); 를 붙여줍니다. (이때 AppConfig.class에는 @Configuration 어노테이션이 붙여있어야 합니다.) ApplicationContext는 스프링 프레임..

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

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

저번 시간에 공부한 http 메서드에 이어 http 상태코드에 대해 알아보자. 웹 페이지 개발을 조금이라도 건들여 본 사람이라면 프론트엔드와 백엔드 연동 시, 상태코드에 대해 접해본 적이 있을 것이다. 클라이언트 측에서 HTTP 요청 메시지를 보내면 , 서버에서 요청에 대한 처리를 하고 클라이언트에게 결과 응답 메시지를 보내준다. 이 경우 응답메시지 시작 부분에 200 과 같은 상태코드가 나타나는데 , 이 상태코드에 대해서 알고 있어야 제대로 처리가 되었는지, 오류가 발생했는지 오류가 발생했다면 무슨 오류인지 알 수 있다. 크게 다음 5개의 상태코드로 나타낼 수 있다 1xx (informational): 요청이 수신되어 처리 중인 상태. 2xx (Successful) : 요청 정상 처리 3xx (Redi..

*공부한 내용을 복습하기 위해 작성한 내용이며, 중간에 옳지 않은 내용이 포함될 수 있음.* 전 시간에 URL을 통한 통신과정을 보며 HTTP 요청 메시지를 주고받는 모습을 볼 수 있었다, 오늘은 HTTP 메시지에 대해서 알아보자. HTTP 메시지에는 정말 많은 것을 담을 수 있다. HTML , TEXT IMAGE, 음성, 영상 파일 JSON, XML (API) 위의 형식 등등 서버간에 데이터를 주고받을 때 대부분 HTTP를 사용한다. HTTP에도 발전 역사가 존재하는데, 그 중 HTTP는 HTTP/1.1 버전으로 가장 중요한 버전이다. (그 외에도 HTTP/2 , HTTP/3 버전이 있는데 HTTP/1.1을 베이스로 성능개선한 버전이다.) TCP / UDP에 대해서도 전 시간에 배웠었는데 HTTP 1...