목차 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..
전략 패턴과 템플릿 콜백 패턴 템플릿 콜백 패턴은 전략 패턴을 발전시킨 형태이다. 전략 패턴은 보통 인터페이스와 그것들의 구현체(전략들, Strategy)를 생성해 놓고, Client 클래스가 구현체를 선택하여 그것을 실행시킬 Context 클래스에 주입하여 원하는 전략을 실행시키는 방식으로 구성된다. 이 패턴을 통해 여러 구현체를 만들어놓고, 상황에 따라 Client 클래스의 구현체 선택만을 바꾸는 방식으로 프로그램을 손쉽게 수정할 수 있다. 템플릿 콜백 패턴에선 전략 패턴과 다르게 전략들을 따로 만들어두지 않는다. 그 대신 익명 클래스를 사용해 Client 클래스에서 Context 클래스에 익명 클래스를 통해 전략을 바로 생성하여 주입한다. 템플릿 콜백 패턴을 통해 반복되는 로직을 뽑아내자 반복되는 ..
- Total
- Today
- Yesterday
- JPA
- Spring 테스트
- 의존성 주입
- GitHub Discussion 템플릿
- 함수형 인터페이스
- logback-spring.xml
- java switch case
- RandomPort
- springboottest
- stubbing
- JPA JSON
- GitHub Discussion
- Spring Boot Monitoring
- 생성자 주입
- 우테코
- 우테코 프리코스
- 자바
- Java
- GitHub Discussion Template
- 우테코 5기
- 스프링
- thenComparing
- Payload 암호화
- Jenkins 예약 배포
- invokedynamic
- comparing
- MySQL 이벤트 스케줄
- Spring
- 람다식
- Fromtail
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |