[TIL] DI와 DI 컨테이너
댓글 0
댓글을 작성하려면 로그인이 필요합니다.
아직 댓글이 없습니다. 첫 번째 댓글을 작성해보세요!
우리가 흔히 싱글톤으로 관리하는 코드는 편리하지만 몇가지 문제가 있다
"하나뿐"은 살리고 전역 접근만 걷어내고자 DI와 DI컨테이너 사용
// 싱글턴 수업에서 배운 고전 형태
public class GameManager : MonoBehaviour
{
public static GameManager Instance { get; private set; } // ① 전역 정적 접근
private void Awake()
{
// 같은 매니저를 담은 씬을 다시 로드하면 두 번째가 생긴다 → 이 가드로 지움(안티패턴의 증상)
if (Instance != null && Instance != this) { Destroy(gameObject); return; }
Instance = this;
DontDestroyOnLoad(gameObject); // ② 씬을 넘어 생존
}
}
| 묶인 특성 | 무엇인가 | DI는 무엇으로 대체하나 |
|---|---|---|
① 전역 정적 접근(.Instance) | 어디서나 끌어다 쓰는 접근/가시성 | 주입: 의존을 시그니처로 받음(3·5절) |
② 씬 생존(DontDestroyOnLoad) | 씬을 넘어 사는 수명/스코프 | Root LifetimeScope의 Singleton 수명(3차시) |
핵심은 필요한 의존을 전역에서 꺼내(pull)쓰지 않고, 어떻게 밖에서 건네받게(push)할까?
Dependency Injection: 가져오기(pull)을 건네받기(push)로 뒤집는 것
객체가 필요한 의존을 스스로 찾지 않고 밖에서 건네 받음(주입)
new, .Instance, FindObjectOfType, GameObject.Find, GetComponent로 씬을 뒤져 캐싱 = pull
[SerializeField] 인스펙터 드래그 = push
DIP(원칙)와 DI(기법)
DIP는 SOLID에 종속성 역전 원칙 "구체가 아니라 추상화에 의존하라"
DI는 그 원칙을 코드로 실현하는 기법 "어느 방향으로 의존해야 하는가"
한계
조립 지점의 수작업을 자동화하는 라이브러리. 어떤 컨테이너든 핵심은 다음 세 동작
| 동작 | 답하는 질문 | 컨테이너가 하는 일 |
|---|---|---|
| 등록(Register) | 무엇을, 어떤 수명으로? | “IAudioService가 필요하면 AudioManager를 줘라” 같은 조립 규칙을 한곳에 모아 둠 |
| 해석(Resolve) | 이 타입 하나 줘 | 생성자 시그니처를 분석해 필요한 의존을 재귀적으로 만들어 끼움, 그래프 자동 조립 |
| 수명(Lifetime) | 몇 개나, 언제까지? | 하나를 공유할지 매번 새로 만들지 결정하고, 스코프가 끝나면 Dispose까지 관리 |
XR을 활용한 게임 개발 3기(유니티) 수강생입니다. 곧 수료 하지만 앞으로 이곳에 가끔 저의 개발 경험이 나 지식 기록할까 합니다. 더 나아가 이 사이트가 제 개인위키의 역할을 할 수 있으면 좋겠습니다. 한국 게임 시장을 흔들겠습니다

게임 광고 수익은 단순히 광고를 붙이는 것이 아니라, 여러 광고 네트워크를 경쟁시켜 가장 높은 수익을 만드는 구조입니다.

안녕하세요. 플밍 4기 입니다. 게임 개발을 배우기 전 네트워크 엔지니어 도메인에서 익히고 배웠던 네트워크 이론에 대한 기초 입니다. 학습에 도움이 되길 바라며 공유 드립니다.