주요 구현 내용 요약
1. 싱글톤 패턴 리팩토링 (MonoSingleTon<T>상속)
2. 싱글톤이 필요한 컴포넌트와 그렇지않은 컴포넌트 명확히 구분
3. 코드 구조,주석,region 활용으로 가동성 강화
1. 싱글톤 패턴 리팩토링 (MonoSingleTon<T>상속)
- 기존에 직접적으로 public static EquipManager Instance;를 두고 Awake에서 수동 할당하는 방식에서,
MonoSingleton<T> 패턴을 상속하여 더욱 안전하고 일관된 싱글톤 구조로 리팩토링했다. - 이 과정에서 Instance 직접 할당, 중복 생성/파괴 문제를 MonoSingleton에서 자동으로 관리하게 되어
싱글톤 관련 버그 가능성이 줄어들었고, 코드도 더 간결해졌다. - 씬에 없는 경우 자동 생성, DontDestroyOnLoad, 어플리케이션 종료 처리 등도 MonoSingleton에서 일괄로 처리된다.
2. 싱글톤이 필요한 컴포넌트와 그렇지않은 컴포넌트 명확히 구분
- EquipManager 전역적 관리가 필요한 매니저 클래스만 싱글톤으로 설계.
- CharacterVisual처럼 각 캐릭터마다 인스턴스가 필요한(여러 개 등장하는) 클래스에는
절대 싱글톤을 적용하지 않고 MonoBehaviour로 유지하도록 명확히 구분했다. - 싱글톤 오용시 오히려 버그 발생 위험이 있다는 점을 다시 한 번 실감함.
3. 코드 구조,주석,region 활용으로 가동성 강화
- 각 클래스/함수별로 역할을 명확히 드러내는 주석과 region을 적극적으로 활용해서
타인 또는 미래의 내가 봐도 이해하기 쉬운 코드 구조를 만들 수 있었다. - 코드 리뷰나 협업 시에도 커뮤니케이션 효율이 높아질 것 같다고 느낌.
느낀점
- 싱글톤 패턴을 제대로 이해하고 적용하는 것의 중요성을 체감했다.
잘못 쓰면 오히려 꼬이거나 디버깅이 어려워질 수 있는데, MonoSingleton을 활용하면서
"진짜 전역 관리가 필요한 매니저만" 싱글톤으로 관리해야 한다는 원칙이 명확해졌다. - 인벤토리/장비 시스템을 구조적으로 분리하고 각 클래스/함수 역할을 명확히 나누면서
유지보수와 확장성 측면에서 훨씬 편해질 거라는 자신감이 생겼다. - region과 XML 주석을 습관적으로 쓰니까, 과제 제출이나 팀 프로젝트 때 설명 부담도 줄어들고
코드를 보는 사람 입장에서도 훨씬 신뢰감이 높아질 것 같음. - 앞으로도 여러 개 만들어질 수 있는 컴포넌트는 절대 싱글톤을 쓰지 않는다는 원칙을 명확히 지키려고 한다.