[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_34일차

Recording/멋쟁이사자처럼 BE 13기

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_34일차_"스프링 Optional, Annotation"

LEFT 2025. 1. 20. 18:27

🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [34]일차

🚀34일차에는 필드를 통한 의존성 주입에 대한 공부와 Optional객체, Annotation 등에 대해 배울 수 있었다.

먼저 회고를 통해 이해가 어려웠던 생성자, 설정자 부분의 복습해야할 것 같다.

설정자를 통한 의존성 주입

UserExam 클래스

사용자가 웹페이지에 접속하여 회원가입을 요청 (main)

// UserController를 주입받음
public class UserExam {
    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext(UserConfig.class);
        UserController controller = context.getBean(UserController.class);
        controller.joinUser();
    }
}

new AnnotationConfigApplicationContext(UserConfig.class);
➡️UserConfig 클래스의 Bean들을 스캔하여 컨테이너에 등록
context.getBean(UserController.class);
➡️UserController Bean을 컨테이너로부터 가져옴.
UserController는 UserService 클래스의 의존성이 주입된 상태로 반환
controller.joinUser();
➡️UserController의 joinUser()메소드로부터 UserService 인터페이스에 요청을 전달
UserService인터페이스를 구현한 UserServiceImpl 구현체 클래스로 의존성이 주입되어 joinUser()의 정보가 전달됨

UserConfig 클래스

모든 클래스와 의존성을 관리하는 컨테이너, 설정 클래스
이 Spring컨테이너에서 모든 Bean이 등록되고 관리 (설정 클래스)
= 모든 클래스와 의존성을 @Bean으로 설정하고 의존성 주입을 관리함

@Configuration
public class UserConfig {
    @Bean
    public UserDao userDao(){ // UserDao Bean으로 등록
        return new UserDaoImpl(); // UserDao 인터페이스의 구현체
    }

    @Bean
    public UserService userService() {
        UserServiceImpl userService = new UserServiceImpl();
        userService.setUserDao(userDao()); // UserDao 의존성 주입
        return userService;
    }

    @Bean
    public UserController userController() {
        UserController userController = new UserController();
        userController.setUserService(userService()); // UserService 의존성 주입
        return userController;
    }
}

UserService service = new UserServiceImpl();
➡️선언은 인터페이스타입으로, 생성은 구현체로한 것처럼

@Bean
public UserDao userDao(){
    return new UserDaoImpl();
}

Bean을 등록할때에도 타입은 인터페이스로 실제 생성은 구현체로 반환

UserConfig 클래스 - 생성자를 통한 주입방법

// 기존 설정자 주입방법
@Bean
public UserService userService() {
    UserServiceImpl userService = new UserServiceImpl();
    userService.setUserDao(userDao()); // 설정자로 UserDao 의존성 주입
    return userService;
}
@Bean
public UserController userController() {
    UserController userController = new UserController();
    userController.setUserService(userService()); // 설정자로 UserService 의존성 주입
    return userController;
}
//-----------------------------------------
// 바뀐 생성자 주입방법
@Bean
public UserService userService() {
    return new UserServiceImpl(userDao()); // 생성자 호출
}

@Bean
public UserController userController() {
    return new UserController(userService()); // 생성자 호출
}

setUserDao와 setUserService 메소드 호출 제거
각 객체를 생성할때에 생성자를 통해 의존성을 주입하도록 바꿀 수 있음

UserController 클래스

회원가입 요청을 접수받아서, 사용자의 요구사항에 따라 요청을 처리하는 서버로 전달 (서비스 계층 호출)

// UserService를 주입받음 (사용자의 요청을 처리하고 서비스 계층(UserService)에 전달)
public class UserController {
    // 유저컨트롤러를 요청하면 UserService에 의존하고 있을 것
    private UserService userService;

    public void setUserService(UserService userService) {
        this.userService = userService;
    }

    public void joinUser(){
        User user = new User();
        user.setName("jones");
        user.setEmail("premier@league.com");
        user.setPassword("1111");

        userService.joinUser(user);
    }
}

UserController가 UserService에 의존하고 있다.
(=UserController가 생성되기 위해서는 UserService가 먼저 생성되어야한다.)
실제로 동작할때는 User정보를 사용자한테 받아올 것 (사용자가 정보를 주면서 회원가입해달라고 요청할 것)

UserController 클래스 - 생성자를 통한 주입방법

// 기존 설정자 주입방법
private UserService userService;
public void setUserService(UserService userService) {
    this.userService = userService;
}
//--------------------------------
// 바뀐 생성자 주입방법
private final UserService userService; // final 키워드 추가
public UserController(UserService userService) { 
    this.userService = userService;
}

setUserService 설정자 메소드 제거
생성자에서 UserService의 의존성을 받도록 변경
final키워드 추가로 의존성이 바뀌지 않도록 함

UserService 인터페이스와 UserServiceImpl 구현체 클래스

회원가입 요청을 처리하는 서버
(데이터계층을 호출하여 데이터를 가져오거나 회원가입요청에 대한 응답을 수행)

public interface UserService {
    public void joinUser(User user);
}

// UserDao를 주입받음 (비즈니스 로직 수행 및 데이터 계층(UserDao) 호출)
public class UserServiceImpl implements UserService{
    private UserDao userDao;

    public void setUserDao(UserDao userDao) {
        this.userDao = userDao;
    }

    // UserController 클래스 -> UserService 인터페이스로부터 주입받은 User객체를 처리
    @Override
    public void joinUser(User user) {
        userDao.addUser(user); // 유저를 넣어보내 저장하는 메소드
        // UserDao 인터페이스의 메소드 addUser()호출
        // UserDao인터페이스를 구현한 UserDaoImpl 구현체 클래스로 의존성이 주입되어 (>> addUser()의 정보가 전달됨)
    }
}

UserService가 UserDao에 의존하고 있다.
(=UserService가 생성되기 위해서는 UserDao가 먼저 생성되어야한다.)
➡️userDao.addUser(user) 처럼 userDao가 있어야 메소드를 수행할 수 있음

UserServiceImpl 구현체 클래스 - 생성자를 통한 주입 방법

// 기존 설정자 주입방법
private UserDao userDao;
public void setUserDao(UserDao userDao) {
    this.userDao = userDao;
}
// -------------------------------
// 바뀐 생성자 주입방법
private final UserDao userDao; // final 키워드 추가 (의존성 불변)
public UserServiceImpl(UserDao userDao) { 
    this.userDao = userDao;
}

setUserDao 설정자 메소드를 제거하고 생성자에서 의존성을 받도록 함
userDao 필드에 final키워드를 추가하여 의존성 변경이 불가능하도록 함

UserDao 인터페이스와 UserDaoImpl 구현체 클래스

데이터를 제공하거나 데이터를 저장하는 “창고” 개념

public interface UserDao {
    public User getUser(String email);
    public List<User> getUsers();
    public void addUser(User user);
}

// 주입받지 않고 직접 구현체로 사용 (데이터 저장 및 처리를 담당)
public class UserDaoImpl implements UserDao{
    @Override
    public User getUser(String email) {
        return null;
    }
    @Override
    public List<User> getUsers() {
        return null;
    }
    // UserDao 인터페이스의 addUser()메소드를 오버라이딩 (구현체)
    @Override
    public void addUser(User user) { // UserServiceImpl 구현체 클래스로부터 User객체를 전달받아 메시지 출력
        System.out.println(user.getName() + "의 정보가 성공적으로 저장되었습니다.");
    }
}

❓설정자 주입방식에서 생성자 주입방식으로 바꾸게되면서의 장점

➡️의존성을 강제할 수 있음
생성자에 의존성을 정의하여 의존성 없이는 객체를 생성할 수 없으므로
의존성을 필수적으로 주입하도록 할 수 있음

@ComponentScan

UserConfig에서 @Bean처럼 등록했던 부분을 @ComponentScan으로 바꿔 자동으로 Bean 등록

@ComponentScan(basePackages = "com.example.iocexam") // 어느 디렉토리를 스캔할 것인지 지정
public class UserConfig {
//...Bean 주석
}

// UserDao를 주입받음 (비즈니스 로직 수행 및 데이터 계층(UserDao) 호출)
@Service
public class UserServiceImpl implements UserService{

// 주입받지 않고 직접 구현체로 사용 (데이터 저장 및 처리를 담당)
@Repository
public class UserDaoImpl implements UserDao{

// UserService를 주입받음 (사용자의 요청을 처리하고 서비스 계층(UserService)에 전달)
@Controller
public class UserController {

인터페이스가 아닌 구현체에 붙여준다.
또한 이들은 @Component를 포함하기때문에 @ComponentScan의 대상에 해당된다.

@Autowired

오토 와이어드
이 어노테이션이 붙은 것에는 자동으로 의존성 주입 가능
ComponentScan의 대상이 되는 것에 @Autowired를 지정
[생성자 @Autowired] : 만약 기본 생성자와 @Autowired 어노테이션의 생성자가 있을때
@Autowired가 붙은 생성자를 먼저 스캔하게되고, 기본생성자는 자연스럽게 스캔 대상에서 제외된다.
[설정자 @Autowired] : 설정자를 통한 스캔도 마찬가지로 Setter메소드에 @Autowired를 붙여서
명시적으로 스캔의 대상을 지정하고 실행할 수 있다.
@Repository는 어느 것도 주입받고 있지 않으므로 @Autowired로 스캔 대상을 지정할 필요가 없다.
생성자, 설정자, 필드 주입방식에서 모두 사용 가능
의존성 주입 우선 순위 : 필드 → 설정자 → 생성자

❓필드를 통한 의존성 주입을 권장하지 않는 이유

스프링이 자동으로 수행하므로 스프링에 종속적일 수 있다.
생성자 주입방법과 설정자 주입방법은 각각 생성자와 Setter설정자가 필요하므로
스프링이 아니더라도 의존성 주입이 가능하지만 필드를 통해 의존성을 주입할때에는 스프링이 자동으로 수행
➡️따라서 스프링이 없으면 필드를 통한 의존성 주입 코드는 실행할 수 없을 것이므로
스프링 없이도 실행 가능한 생성자, 설정자 방식과 달리 필드를 통한 주입 방식은 권장하지 않는 방법이다.
생성자를 통해 객체 생성 시 의존성을 한 번에 주입받아 불변성을 확보할 수 있는 것과는 달리
필드를 통한 주입은 객체의 안정성을 보장하기 어려움
➡️객체의 안정성을 보장하기 어려운 이유
- 객체가 생성된 후에도 의존성이 변경될 수 있으므로
- 의존성 주입을 위해 스프링 컨테이너가 필요하게 되므로 테스트가 어렵다.
- 순환참조를 사전에 예방할 수 없음 (객체 A가 객체 B를 의존하는데 객체 B도 객체 A에 의존하는 구조)

@Service
public class ServiceB {

    @Autowired
    private ServiceA serviceA;

    public void run(){
        serviceA.run();
    }
}

@Autowired > private ServiceA serviceA
➡️필드를 통해 의존성을 주입하게 되면 ServiceA와 ServiceB가 서로 참조하게되는 순환참조 구조가 됨
생성자를 통한 의존성 주입은 final 키워드 사용(=불변객체 사용)이 가능하다는 것과는 달리
필드를 통한 의존성 주입은 final(=불변객체)로 고정할 수 없음
➡️객체가 생성되는 시점에 주입되지 않고 객체가 생성된 후에 주입이되므로
final로 선언하게되면 객체 생성 시 상수로 값을 고정하므로 의존성을 주입할 수 없다.
의존성을 숨길 수 없음
➡️필드를 통해 의존성을 주입할때 Reflection API를 사용
생성자, 설정자 주입방식은 내부로직에서 의존관계를 주입(데이터만 넘겨받아 내부로직에서 의존관계 주입)

필드 주입 방식은 Reflection API가 직접 필드에 접근해서 주입하게된다.
➡️외부 API에 의존성이 노출될 수 있음
➡️객체가 캡슐화되어 외부로부터 내부를 보호하는 객체지향프로그래밍 관점에서는 적합하지 않음
테스트가 힘듦
생성자, 설정자 주입방식은 테스트 객체를 매개변수로 넘길 수 있어 원하는 경우 테스트 객체 변경이 가능하지만
필드주입방식은 @Autowired로 직접 필드에 객체를 주입하기 때문에 테스트 과정이 복잡합

❓설정자 주입방식과 생성자 주입방식의 상황 별 장점

➡️의존성 주입이 선택적인 경우에는 “설정자 주입 방식”이 유리
➡️의존성을 필수적으로 강제해야할때는 “생성자 주입 방식”이 유리

스프링에서는 생성자 주입 방식이 권장되지만 상황에 따라 설정자 주입도 유용
➡️생성자 주입방식이 권장되는 이유 : 의존성을 명확히하고, 테스트 가능성과 코드의 유지보수성을높일 수 있기때문

컨테이너 (Container)

인스턴스의 생명주기를 관리
생성된 인스턴스들에게 추가적인 기능을 제공
중간에 끼어들어서 인스턴스 동작을 도와주기도 함
DI컨테이너 자체를 컨테이너라고 부르기도함. (객체 생성과 의존관계 설정을 담당)

DI (Dependency Injection)

의존성 주입
클래스 사이의 의존관계를 Bean 설정 정보를 바탕으로 컨테이너가 “자동으로 연결해주는 것”을 의미
DI 관련 용어 :
➡️Bean :
- 스프링에서 DI를 사용하기 위해 생성되는 객체 (=DI 컨테이너가 관리하는 객체)
- DI컨테이너가 빈을 생성하고, 초기화, 보관, 필요한 곳에 제공까지 담당
- 스프링 컨테이너를 통한 관리의 자동화로 개발자가 복잡한 객체 생성 및 관리 과정에 관여하지 않아도됨
- 기본적으로 싱글턴패턴이어서 하나의 인스턴스만 생성되어
어플리케이션 내에서 해당 Bean에 대한 요청이 있을때마다 동일한 객체 인스턴스가 반환

➡️BeanFactory : 스프링에서 Bean을 생성하고 관리하는 컨테이너

➡️@Component : 스프링에서 Bean을 생성하기위한 어노테이션 중 하나로 해당 클래스를 Bean으로 등록하는 역할

➡️ApplicationContext : BeanFactory를 상속한 스프링 컨테이너로
단순한 기능을 제공하는 BeanFactory를 확장하여 더 다양한 기능을 제공

➡️Autowiring(=자동주입) : 자동으로 Bean을 주입하는 기능으로 @Autowired 어노테이션을 통해 사용

➡️Qualifier : 같은 타입의 Bean이 여러개 있을 경우 어떤 Bean을 사용할지 결정하는 용도로 사용

➡️Configuration(=구성) : DI컨테이너가 객체를 생성하고 의존관계를 설정하기 위해 참조하는 설정정보

@SpringBootApplication

1. 기존 방법 (AnnotationConfigApplicationContext())

public static void main(String[] args) {
    // UserConfig 클래스의 Bean들을 스캔하여 컨테이너에 등록
    ApplicationContext context = new AnnotationConfigApplicationContext(UserConfig.class);
}

기존에 UserConfig 객체를 가져와서 실행하던 방법 (AnnotationConfigApplicationContext 활용)

run()메소드는 ApplicationContext를 반환하므로

2. 두번째 방법 (SpringApplication.run())

@SpringBootApplication
public class IocexamApplication {
	public static void main(String[] args) {
		ApplicationContext context = SpringApplication.run(IocexamApplication.class, args);
		UserController controller = context.getBean(UserController.class);
		controller.joinUser();
	}
}

ApplicationContext에 넣어서 실행이 가능

Optional

null에 대한 처리를 하기 위한 자바에서 추가된 클래스 (객체)
메소드가 반환할 결과 값이 '없음'을 명확할때 사용
NULL 반환 시 에러 발생 가능성이 높은 상황에서 메소드의 반환 타입으로 Optional을 사용
스프링 4부터는 JDK 8부터 추가된 java.util.Optional 객체를 사용할 수 있음

Optional<String> optional = Optional.of("Hello");
if(optional.isPresent()){
	System.out.println(optional.get());
}

of("Hello") : 값이 NULL이 아닌 경우 사용(=값이 반드시 존재해야함), “Hello”값이 존재하는지 확인해서 처리,
ofNullbale() : 값이 NULL일 수도 아닐 수도있는 경우 사용, 값이 NULL이면 빈 Optional객체 반환
orElse(”Hi”) : 값이 없다면 “Hi”라는 대체 값을 넣어주기도함
orElseThrow() : 값이 null이었을때 (값이 없다면) 예외 발생 시키기 (=오류 처리를 강제함)
isPresent() : optional 객체가 값을 가지고 있다면 true, 없다면 false
ifPresent() : 값이 존재할때 실행할 동작을 정의
isEmpty() : 값이 비어있다면 처리할 부분을 구현 가능

▶️실습 - 회원가입 서비스에 적용 : Optional 객체

UserDaoImpl 클래스

Optional반환타입으로 바꿀 메소드는 UserDao 인터페이스에서 먼저 Optional 반환타입으로 수정

// 기존 코드
@Repository
public class UserDaoImpl implements UserDao{
    //...
    @Override
    public List<User> getUsers() {
        return null;
    }
}

// Optional 사용
@Repository
public class UserDaoImpl implements UserDao{
    //...    
    @Override
    public Optional<User> getOptionalUsers() { // 실제 메소드에서는 DB 등에서 데이터를 꺼내옴
        User user = new User();
        return Optional.of(user);
    }
}

리스트 반환타입을 가지는 getUsers()메소드를 Optional 반환타입을 가지는 getOptionalUsers()로 바꿔줄 수 있다.
Optional.of(user) : user값이 NULL이 아닌 경우 사용할 수 있는 메소드

UserServiceImpl 클래스

// 기존 코드
@Service
public class UserServiceImpl implements UserService{
    private UserDao userDao;

    @Autowired
    public void setUserDao(UserDao userDao) {
        this.userDao = userDao;
    }

    @Override
    public void joinUser(User user) {
        userDao.addUser(user); 
    }**
}

// Optional 사용
@Service
public class UserServiceImpl implements UserService{
    // ... 기존 코드
    
    // Getter 추가
    public void getUser(String id){
    	User user = userDao.getOptionalUser().orElseThrow();
  	}
}

orElseThrow() : 값이 없으면 예외를 발생

정리하자면 명시적으로 null체크를 해준 것을 Optional로 간단히 표현이 가능하다는 것

userDao.getOptionalUser().orElse(new User());

Optional객체에서 값을 꺼내오지만 값이 존재하지 않을 경우에는 “새로운 기본 객체”를 반환
즉 예외를 던지기보단 기본값을 제공하여 프로그램이 계속 실행되도록 보장하는 코드

❓Optional 사용의 장점

null 관련 문제 예방 (명시적으로 값의 유무를 처리함)
코드 가독성 향상 (isPresent, orElse, map 등 사용)
안전한 의존성 관리 (Optioanl을 반환타입으로 사용하여 호출자가 결과값에 안전하게 접근 가능)
메소드 반환타입이 Optional이면 호출자가 값이 없을 “가능성을 미리 인지”할 수 있음

❓Optional 사용의 단점

➡️모든 메소드 반환값에 Optional을 사용할 경우 불필요한 복잡성 유발

❓Optioanl 사용 시기

➡️메소드 반환값으로 사용 (값이 없을 가능성이 있는 메소드의 반환타입으로 적합)

Dao객체가 여러 개일때 접근 방법

// 주입받지 않고 직접 구현체로 사용 (데이터 저장 및 처리를 담당)
@Repository
public class UserDaoImpl implements UserDao{
    // ...
}

@Repository
public class UserJuunbImpl implements UserDao{
    //...
}

이처럼 UserDao가 2개가 구현되어있으면 오류가 발생
➡️해결방법 : 타입을 사용한 오토와이어링 방식

타입을 사용한 오토와이어링

Dao 객체의 ID를 명시적으로 지정하지 않으면 클래스 첫글자만 소문자로 바꾼 이름을 “ID”로 판단
ex. UserJuunbImpl 이면 "userJuunbImpl" id로 지정
UserDaoImpl 이면 "userDaoImpl" id로 지정
ID를 지정하는 법 : ex. @Repository(”userDao”), @Repository(”userJuunb”)
Dao 객체를 사용하는 곳에서는
➡️@Qualifier(”userDao”) 처럼 기본생성자 안에서 어노테이션을 명시해야한다.

1. 생성자에서 @Qualifier 사용

// @Qualifier : 생성자에 특정 id의 Dao에게 의존성 주입을 해달라는 표기
public UserServiceImpl(@Qualifier("userDao") UserDao userDao) {
    this.userDao = userDao;
}

UserDao타입의 userDao를 가져올때
UserJuunbImpl (UserDao타입)과 UserDaoImpl (UserDao타입) 2개가 존재하므로
@Qualifier로 userDao의 ID를 지정하여 지정한 ID를 가진 UserDao타입을 가져올 수 있게한다.
만약 public UserServiceImpl(){} 같은 기본 생성자가 공존하면 기본 생성자부터 수행하므로 오류가 발생할 수 있다.
따라서 UserDao 타입을 받는 생성자 사용시 기본생성자를 주석처리하거나 없애주어야
UserDao타입의 생성자에서 @Qualifier 을 사용하는 방식이 오류가 발생하지 않는다.

2. 설정자에서 @Qualifier 사용

@Autowired
public void setUserDao(@Qualifier("userDao") UserDao userDao) {
    this.userDao = userDao;
}

생성자에 @Qualifier를 넣어준것처럼 설정자에 @Qulifier를 넣어줄때는@Autowired와 함께 써주어야한다.

// 주입받지 않고 직접 구현체로 사용 (데이터 저장 및 처리를 담당)
@Repository("userDao")
public class UserDaoImpl implements UserDao{ ... }

@Qualifier 어노테이션은 구현체 클래스의 @Repository 뒤에 명시한 ID를 가져온다.
만약 명시하지 않았다면 자동으로 ID를 판단한다.(ex. ID = userDaoImpl (첫글자만 소문자로))

이름으로 오토와이어링

자바 JSR-250 표준에서 사용하는 @Resource 어노테이션
(이름 기반으로 Bean을 찾아 자동으로 의존성을 주입한다)
스프링에서 공급되는 @Autowired 키워드가 아닌 @Resource 키워드로 대체할 수 있음
➡️대체 키워드를 도입하는 이유 :
일반적으로 스프링을 사용하지만 다른 프레임워크가 들어온다하더라도
사용에 문제가 없도록 표준화하기 위하여 대체 키워드를 도입하였다.
필드 의존성 주입과 설정자 의존성 주입에서 @Resource 어노테이션을 사용할 수 있는 것과 달리
생성자 의존성 주입에서는 @Resource 어노테이션을 사용할 수 없다.

@Configuration vs @ComponentScan

➡️@Configuration :
Java 설정파일로, 설정파일을 읽어 스프링 컨테이너에 Bean을 등록
명시적으로 Bean을 생성하여 사용할때 적합함

➡️@ComponentScan :
지정된 패키지를 스캔하여 @Component관련 어노테이션이붙은 클래스들을 자동으로 Bean으로 등록
명시적으로 Bean을 생성하지 않아도됨

정리하자면 @Configuration 에서는 명시적으로 일부 Bean을 정의하고
나머지는 @ComponentScan으로 Bean을 자동 등록하는 방식을 사용

@Configuration
@ComponentScan(basePackages = "com.example.iocexam")
public class UserConfig {
    @Bean
    public UserDao userDao() {
        return new UserDaoImpl();
    }
}

⭐따라서 두 방식은 명시적인 Bean 등록 (직접 생성) 과 자동 Bean 등록(스캔)의 차이
프로젝트 요구 사항에 따라 적절히 선택

주요 JSR-250 어노테이션들

@Resource : 리소스나 서비스에 대한 참조를 주입받기 위해 사용 이름, 타입 등을 기반으로 의존성 주입
(ex. 세션, 기타 환경 자원 등 주입에 활용)
@PostConstruct : 객체 생성과 의존성 주입이 완료된 후 초기화 목적으로 실행할 메소드에 사용
이 메소드는 객체가 생성된 후 단 한번만 호출되고 초기화작업에서 수행
@PreDestroy : 컨테이너에 의해 빈이 제거되기 전 호출될 메소드에 사용
ex. 리소스 해제, 정리작업 등

@PostConstruct
public void init(){
    // 해당 빈이 생성된 직후 이 메소드를 호출
    System.out.println("빈이 생성된 직후 호출됨.. PostConstruct 실행!");
}

@PreDestroy
public void destory(){
    System.out.println("빈이 소멸되기 전에 호출됨.. PreDestroy 실행!");
}

Annotaion

발음에 따라 어노테이션, 애노테이션 둘 다 가능

@Retention(RetentionPolicy.RUNTIME)
public @interface Count100 {

}

@Retention : 어노테이션 패키지에서 제공하는 어노테이션 (어노테이션을 실행 시기 설정 가능)
@Retention(RetentionPolicy.RUNTIME)
➡️프로그램 실행 중에도 읽을 수 있음 (실행시에도 참조가능)
(=어노테이션이 실행중에도 JVM에 의해 읽힐 수 있음)
➡️스프링에서 AOP(Aspect Oriented Programming)처럼 동적으로 메소드 실행 전/후 동작을 추가하는데 사용 가능

▶️실습 - 사용자 정의 어노테이션 사용

public class Hello {
    @Count100
    public void print(){
        System.out.println("Hello");
    }
}

public class HelloRun {
    public static void main(String[] args) {
        Hello hello = new Hello();
        hello.print();
    }
}

@Count100 어노테이션이 붙으면 약속된 일을 수행하도록함

▶️실습 - 스프링 문법으로 메소드 가져오기

public class HelloRun {
    public static void main(String[] args) throws NoSuchMethodException {
        Hello hello = new Hello();

        Method method = hello.getClass().getDeclaredMethod("print");
        if(method.isAnnotationPresent(Count100.class)){
            // 어노테이션 중에 Count100이 붙은 메소드가 있는지 체크
            for(int i = 0; i < 100; i++){ // @Count100 어노테이션이 붙었으면 100번 출력
                hello.print();
            }
        }else{ // @Count100 어노테이션이 없으면 한번 출력
            hello.print(); // 
        }
    }
}

hello.getClass().getDeclaredMethod("print")
➡️getClass()와 getDeclaredMethod로 가져와서 Method타입에 담는다.
isAnnotationPresent()
➡️Count100 어노테이션이 존재하는지 확인

@Target 어노테이션

@Retention과 함께 어노테이션의 적용범위와 사용방법을 정의하는 “메타 어노테이션”
어떤 “대상”에 어노테이션을 붙일 수 있는지 정의 (클래스, 메소드, 필드, 파라미터 등)
@Target(ElementType.METHOD) 처럼 사용
➡️ElementType을 METHOD로 정의했기때문에 메소드 위에서 어노테이션 정의가능
➡️메소드 위에 어노테이션 정의를 하게 되면 다른 클래스나 필드에서는 사용할 수 없도록 제한

▶️실습 - 사용자 정의 어노테이션 사용 2

getDeclaredMethods()
➡️getDeclaredMethod와 달리 배열을 반환하여 배열값을 받아올 수도 있다.

public static void main(String[] args) {
    Service service = new Service();
    
    Method[] declaredMethods = Service.class.getDeclaredMethods();
}

만든 클래스의 정보들을 얻어올 수 있는 기능을 자바가 제공
Service.class.getDeclaredMethods()
➡️Service의 메소드들을 추상화한 배열을 얻어올 수 있는 것임

for(Method method : declaredMethods){
    if(method.isAnnotationPresent(PrintAnnotation.class)){
        PrintAnnotation printAnnotation = method.getAnnotation(PrintAnnotation.class);
        for(int i = 0; i < printAnnotation.number(); i++){
            System.out.println(printAnnotation.value());
        }
        System.out.println();
    }
}

isAnnotationPresent() : 사용자 정의 PrintAnnotation 어노테이션이 메소드에 붙어있는지 확인
method.getAnnotation(PrintAnnotation.class)
➡️printAnnotation 타입의 객체를 만드는데 getAnnotation()메소드를 활용하여
@PrintAnnotation 이 붙은 메소드를 찾아 가져옴

public class Service {
    @PrintAnnotation
    public void methodA(){
        System.out.println("methodA 실행!");
    }

    @PrintAnnotation("BBB")
    public void methodB(){
        System.out.println("methodB 실행!");
    }

    @PrintAnnotation(number = 10)
    public void methodC(){
        System.out.println("methodC 실행!");
    }

    @PrintAnnotation(value = "#", number = 20)
    public void methodD(){
        System.out.println("methodD 실행!");
    }
}

어노테이션의 속성에 따라 각기 다양한 동작을 할 수 있도록 구현 가능

🚀 회고를 통해 더 궁금했던 부분이었던

필드를 통한 의존성 주입, Optional 사용의 장단점, @Configuration과 @ComponentScan의 차이점 등을 공부할 수 있었다.

스프링이 익숙치 않아서인지 여전히 배울 것이 많은 것 같다.

아직까지는 완벽히 이해할 수 없어서 추가적으로 계속 공부를 해야할 것 같다.

저작자표시 (새창열림)