필드 주입도 순환 참조를 검사해 준다? 스프링의 의존성 주입과 관련하여 코드를 작성해 보던 중, 필드 주입 또한 순환 참조를 검사해 주는 것을 확인하여 의문이 생겼다. 기존에 생성자 주입을 권장하는 이유는 빈의 생명주기 중 처음 두 단계 중 1번의 인스턴스 생성을 위한 생성자 호출에서 바로 의존성을 주입해야 하므로 순환 참조를 찾을 수밖에 없기 때문으로 이해했다. 빈 객체의 인스턴스 생성 단계 의존성 주입 단계 @PostConstruct나 InitializingBean 인터페이스의 구현 메서드에 의한 초기화 단계 스프링 컨테이너 종료 시 @PreDistroy나 DisposableBean 인터페이스의 구현 메서드에 의한 소멸 단계 이번에 새로 경험한 것은 생성자 주입이 아닌 필드 주입과 같은 방법으로 빈을..
목차 1. @Autowired 어노테이션 2. @Autowired를 통한 의존성 주입 방법 3. 생성자 주입을 사용하는 이유 4. @Primary 혹은 @Qualifier를 통해 주입될 구현체 명시하기 @Autowired 어노테이션 스프링 컨테이너에 어노테이션을 통해 빈을 등록하는 방법은 크게 두 가지다. @Bean 어노테이션을 통한 빈 등록 (메서드 레벨) @Component 어노테이션을 통한 빈 등록 (클래스 레벨) @Bean의 경우 메서드에 붙여 해당 메서드를 통해 반환되는 객체를 Bean으로 관리할 때 사용한다. 이와 달리 @Component는 클래스에 붙여 해당 클래스 타입을 기반으로 빈을 관리하도록 한다. @Repository, @Service, @Controller 등의 어노테이션들은 @Co..
Stack을 쓰지 말라 프로그래밍에 조금만 익숙하다면 Stack과 Queue라는 자료구조를 알 것이다. 각각 LIFO(Last In First Out), FIFO(First In First Out)가 필요한 상황에 흔히 사용된다. java.util의 Stack은 Vector를 상속받아 구현되었는데 Vector는 대표적인 자바의 레거시 클래스로 Stack 또한 이 단점을 그대로 가지고 있다. A more complete and consistent set of LIFO stack operations is provided by the Deque interface and its implementations, which should be used in preference to this class. For exam..
try-finally의 단점 InputStream, OutputStream과 java.sql.Connection과 같은 자원은 close 메서드를 사용자가 직접 호출해 닫아주어야 한다. 이런 자원을 직접 닫아주지 않아도 gc가 알아서 처리해주긴 하지만 그 시점을 정확히 알 수 없기 때문에 직접 닫아주는 것이 가장 안전하다. Java7 이전에는 자원의 닫힘을 처리하기 위해 try-finally가 사용되었다. BufferedReader를 사용해 한 줄의 콘솔 입력을 받는 메서드는 아래와 같다. String readLine() throws IOException { BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); try { re..
동일성과 동등성 '동일하다'와 '동등하다'는 거의 같은 단어처럼 들리겠지만 프로그래밍에서는 큰 차이를 가지고 있다. int나 double 같은 기본 타입의 경우 우리는 '==' 연산자를 통해 같음을 확인한다. 그러나 객체의 경우 우리가 같다고 취급하고 싶어도 equals 메서드 혹은 '==' 연산자로 동일함이 확인되지 않는다. System.out.println(1 == 1); // true // 리터럴로 생성된 string은 string pool에 담겨 같은 객체가 재사용된다. String string1 = "string"; String string2 = "string"; System.out.println(string1 == string2); // true System.out.println(string1..
가변 인수(Varargs) 사용하기 Java 5 이전에는 메서드에 다른 개수의 인수들을 넣기 위해서는 메서드를 여럿 정의하거나 배열의 형태로 인수를 넘겨주어 처리해야 했다. Java 5의 가변 인수(Varargs)의 등장으로 Object... 와 같이 메서드의 인수를 0개 이상 받을 수 있게 선언이 가능해지며 이러한 불편함이 사라지게 되었다. public void method(String... strings) { for (String string : strings) { System.out.println(string); } } // method("a", "b", "c") 와 같이 사용 이렇게 가변 인수를 통해 입력을 배열처럼 편하게 처리할 수 있는 지금과 달리 public void method(String..
- Total
- Today
- Yesterday
- Spring
- 우테코
- Payload 암호화
- 우테코 프리코스
- GitHub Discussion 템플릿
- logback-spring.xml
- java switch case
- Spring Boot Monitoring
- MySQL 이벤트 스케줄
- 생성자 주입
- JPA
- GitHub Discussion
- 람다식
- Spring 테스트
- MySQL
- Jenkins 예약 배포
- GitHub Discussion Template
- Java
- Fromtail
- RandomPort
- JPA JSON
- 우테코 5기
- multiplebagsfetchexception
- 의존성 주입
- 자바
- springboottest
- stubbing
- 함수형 인터페이스
- 스프링
- invokedynamic
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |