| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- 스타일 지침
- 데이터 형식
- Render Mode
- 상태 패턴
- event bus
- Canvas Scaler
- github desktop
- New Input System
- 이벤트 버스
- 구글플레이콘솔
- Visual Studio Installer
- 테이블 데이터
- 프로젝트 생성
- 구글 스프레드 시트
- Unity 기술면접
- 콘솔 앱
- MVP 패턴
- C#
- 개발
- Di
- 오브젝트 풀
- Dependency Injection
- 게임 디자인 패턴
- 의존성 주입
- unity
- 유니티
- 추상 팩토리 패턴
- 기술면접
- Abstract Factory Pattern
- Object Pool
- Today
- Total
목록Dependency Injection (2)
DevDino
의존성 주입 패턴(Dependency Injection Pattern)게임을 개발하다 보면 플레이어가 데미지를 입었을 때 소리를 내기 위해 AudioManager.Instance.PlaySound()처럼 싱글톤(Singleton)을 호출하는 경우가 아주 흔합니다.하지만 이렇게 작성하면 플레이어 클래스는 특정 오디오 매니저에 '강하게 결합(Tight Coupling)'되어버립니다. 만약 테스트를 위해 소리를 끄고 싶거나, 다른 씬에서 다른 오디오 매니저를 사용해야 한다면 플레이어의 내부 코드를 직접 수정해야 하는 문제가 발생합니다. 이처럼 객체가 스스로 필요한 부품(의존성)을 찾거나 만들어 쓰는 대신, 외부에서 조립해서 넣어주는(주입하는) 방식인 '의존성 주입(DI)'패턴에 대해 알아보겠습니다. 의존성 주..
처음에는 프로젝트 내 주요 클래스에만 싱글톤을 썼지만, 나중에는 참조하기 편하다는 이유로 남용하곤 했습니다. 하지만 프로젝트 규모가 커지면서 기존에 사용하던 싱글톤 패턴의 한계가 명확해졌습니다. 클래스 간 결합도가 높아져 수정 사항이 생길 때마다 참조하는 코드들을 일일이 찾아 고쳐야 했습니다. 게다가 싱글톤은 게임이 시작될 때부터 끝날 때까지 메모리에 남아 있다 보니, 초기화 순서가 꼬여 에러가 나거나 메모리 관리가 제대로 되지 않는 문제도 잦았습니다. 그렇다고 임의로 생명주기를 건드리면, 다른 클래스에서 언제 해당 싱글톤을 호출할지 몰라 참조 오류가 날 위험이 생겼습니다. 이러한 문제를 해결하기 위해 의존성 주입(DI, Dependency Injection)을 도입했습니다. 이번 글에서는 유니티 환경..