1)Singleton 패턴이란?
소프트웨어 디자인패턴에서 싱글턴 패턴(Singleton pattern)을 따르는 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다. 이와 같은 디자인 유형을 싱글턴 패턴이라고 한다. 주로 공통된 객체를 여러개 생성해서 사용하는 DBCP(DataBase Connection Pool)와 같은 상황에서 많이 사용된다.
ex)
public class Coin {
private static final int ADD_MORE_COIN = 10;
private int coin;
private static Coin instance = new Coin(); // eagerly loads the singleton
private Coin() {
// private to prevent anyone else from instantiating
}
public static Coin getInstance() {
return instance;
}
public int getCoin() {
return coin;
}
public void addMoreCoin() {
coin += ADD_MORE_COIN;
}
public void deductCoin() {
coin--;
}
}
2) Bean이 무엇이고, 어떻게 만들어지고, 어떻게 쓰이나요?
정의: Bean은 Spring IoC 컨테이너가 직접 생성하고, 관리해주는 객체입니다.
- 일반적인 Java 객체이지만,
- Spring이 대신 생성하고 생명주기까지 관리합니다.
- 보통 서비스, DAO, 컴포넌트 등으로 사용됨
쉽게 말해: "스프링이 대신 new 해주고, 필요할 때 꺼내 쓸 수 있는 객체"
@Bean 어노테이션
@Configuration
public class AppConfig {
@Bean
public UserService userService() {
return new UserService();
}
}
- 개발자가 직접 객체 생성 과정을 제어할 수 있음
- 복잡한 초기화나 조건이 필요한 경우 적합
Bean을 쓰는 방법 = 의존성 주입(DI) 으로 사용합니다
생성자 주입
@Service
@RequiredArgsConstructor
public class OrderService {
private final UserService userService; // Bean 자동 주입
}
3) 스프링 컨테이너는 무엇을 하나요? 어떻게 만들어지고 어떻게 쓰이나요?
스프링 컨테이너는 객체(Bean)를 생성하고, 관리하고, 주입(DI)하는 역할을 하는 핵심 구조입니다.
- 우리가 @Component, @Service 등을 붙인 클래스를 찾아서 Bean으로 만들고,
- 필요할 때 자동으로 꺼내서 주입해 줍니다.
- 즉, 애플리케이션 전체 객체를 관리하는 "공장 + 창고" 역할을 합니다
기능 설명
| 객체 생성 | @Component 등으로 등록된 클래스의 객체(Bean)를 생성 |
| 의존성 주입(DI) | 필요한 객체를 자동으로 주입 |
| 생명주기 관리 | Bean 생성 → 초기화 → 소멸까지 전 과정을 관리 |
| AOP 처리 | 런타임에 프록시 객체를 만들어 기능 확장 |
| 이벤트 처리 | 컨테이너 수준의 이벤트 리스너 및 발행 가능 |
① 자동 생성
@SpringBootApplication
public class MyApplication {
public static void main(String[] args) {
SpringApplication.run(MyApplication.class, args);
}
}run() 메서드가 스프링 컨테이너를 자동으로 만들어 줍니다.
4) DI는 무엇이고, 왜 쓰이며, 어떻게 쓰이나요?
객체가 의존하는 다른 객체를 직접 생성하지 않고,외부에서 주입받도록 하는 설계 방식
즉, 필요한 객체를 스스로 new 하지 않고,
Spring 컨테이너가 대신 만들어서 넣어주는 것입니다.
이유 설명
| 결합도 낮춤 (Low Coupling) | 클래스 간 강한 연결 없이 협력 가능 → 유지보수 편리 |
| 재사용성 증가 | 다른 객체로 쉽게 교체 가능 (예: Mock 객체) |
| 테스트 쉬움 | 테스트할 때 가짜 객체(Mock)를 주입할 수 있음 |
| 확장성 증가 | 실제 구현체를 바꾸는 일이 쉬움 (전략 패턴처럼 작동 가능) |
생성자 주입
@Service
@RequiredArgsConstructor
public class OrderService {
private final UserRepository userRepository;
// 스프링이 생성자 호출 시 자동으로 userRepository 주입
}@RequiredArgsConstructor는 final 필드를 자동으로 생성자에 포함시켜줍니다.
5)IoC의 정의에 대해 설명해주세요. IoC가 왜 필요하고 어떻게 쓰이나요?
객체의 생성과 제어 권한을 개발자가 아닌 프레임워크(SPRING)가 담당하도록 하는 원칙
원래는 개발자가 new를 통해 객체를 만들고, 연결하고, 사용하는 모든 흐름을 직접 제어했지만,
IoC를 통해 이 책임을 스프링 컨테이너가 대신 수행하게 만드는 것입니다.
필요성 설명
| 객체 간 결합도 감소 | 코드가 유연해지고, 한 객체 변경이 다른 객체에 영향을 덜 줌 |
| 재사용성 증가 | 같은 객체를 다양한 상황에서 재활용 가능 |
| 테스트 쉬움 | 테스트 시 다른 객체(가짜 객체 등)로 쉽게 대체 가능 |
| 유지보수 쉬움 | 구조적으로 깔끔하고 역할 분리가 명확함 |
1) IoC 컨테이너 생성
ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
- 위 코드에서 context가 바로 IoC 컨테이너
- 내부적으로 모든 Bean 객체를 생성하고 의존 관계를 주입함
2) Bean 등록
@Component
public class UserService { }
@Component를 통해 IoC 컨테이너가 UserService 객체를 만들고 보관합니다
3) Bean 주입 (DI를 통해 사용)
@Service
@RequiredArgsConstructor
public class OrderService {
private final UserService userService; // IoC가 이 객체를 주입함
}- 개발자는 new를 쓰지 않음
- IoC 컨테이너가 필요한 객체를 알아서 넣어줌 → DI(의존성 주입)은 IoC의 구현 방식 중 하나