[💬] 싱글톤을 안쓰는 방법이 있음?

[익명(218.209)]

밑에 글에 싱글톤 쓰면 의존성을 숨긴다는데

그럼 싱글톤 안쓰는 방법좀 알려줘

검색해보면 죄다 쓰지말자라는 말만 하고

안쓰는 방법은 안알려주네

[ㅇㅇ 1(112.163)]

쓰지말라는게 아니라, 사용하기엔 편해지긴 해도 궁극적으로 싱글톤을 사용하게 되면 해당 클래스에 대한 의존성이 있는지 없는지 판단하기 위해서 소스 코드를 다 뒤져 봐야 함. 만약에 외부에서 내가 의존하는 인스턴스에 대한 참조를 명시적으로 전달 받았다면 그러지 않아도 되었겠지. 그리고 싱글톤의 경우엔, 그 자체가 뭔가 클래스간 의존성을 줄여주진 않음.

[ㅇㅇ 1(112.163)]

그렇다고 싱글톤이 아주 그냥 악이냐? 그렇지는 않음 만약 프로그램/라이브러리에서 전역적으로 접근 해야 하지만(로거 등) 인스턴스가 하나인 것을 강제해야 하는 경우, 싱글톤은 전역 변수 보다 더 나은 해법임.

[ㅇㅇ 1(112.163)]

예를 들어, 인스턴스가 유일해야하는 서브 시스템 'A'가 프로그램 전체에 걸쳐 의존성이 존재 할 가능성이 높다고 가정하자. 그러면 가장 기본적인 방법은 이 'A'의 전역 인스턴스를 만들고 모든 모듈에서 이 전역 인스턴스에 접근 하는 거임. 그런데 이런 경우, 소스 코드 상으로 전역 인스턴스의 생성을 허용하기 위해선 생성자를 public으로 둬야함. 이 경우 1차적으로 전역 인스턴스 외에도 실수던 아니던 서브 시스템 'A'의 인스턴스가 의도치 않게 2개 이상 만들어질 가능성이 생김. 문서화를 해둬도 궁극적으로 '불가능' 하지는 않다는 점이 문제인거고.

[ㅇㅇ 1(112.163)]

두 번째로 2개 이상 인스턴스가 만들어질 가능성이 있다면, 실수로 원래 전역 인스턴스를 새로운 인스턴스로 덮어 씌워버릴 수 있는 경우도 생길 수 있음. 이 경우, 만약 처리를 잘해뒀다 해도 의도치 않은 자원의 할당/해제가 일어 날 수 있고. 그렇다 하더라도 원래 의도와는 다른 행동을 할 가능성이 있다는 걸 짐작 할 수 있을거야.

[ㅇㅇ 1(112.163)]

더 나아가서, 멀티 스레드 환경을 고려하면 이런 상황은 매우 매우 위험하고, 정의되지 않은 행동을 일으킬 가능성이 있어. 예를 들어, 스레드 T1, T2가 있고 얘네가 하나의 전역 인스턴스 'A'를 공유해, 멀티 스레드 상황을 고려해서 전역 인스턴스 'A'의 타입 'ClassA' 내부에는 critical section을 제대로 형성 해뒀어. 하지만 그렇다 하더라도 전역 인스턴스 'A' 자체에 대한 race condition을 막을 순 없어. 이 상황에서 소스 코드에 실수로 전역 인스턴스 'A'에 새로운 인스턴스를 생성 해서 대입해버리는 실수를 저질렀다고 해보자. 상상만 해도 끔찍하지..

[ㅇㅇ 1(112.163)]

이제 다시 싱글톤 패턴의 실제 구현을 들여다 보면, 1. 싱글톤 클래스의 생성자는 private 2. 싱글톤 클래스의 인스턴스를 얻기 위한 메서드는 해당 클래스의 정적 메서드 3. 싱글톤 클래스의 인스턴스는, 싱글톤 클래스의 private 정적 변수 이거나, 인스턴스를 얻는 정적 메서드 내부의 정적 변수 1, 2를 통해서 위에서 첫 번째 예시의 경우를 방지 할 수 있고 2, 3을 통해서 두 번째 예시의 경우를 사전에 방지 할 수 있지 그리고 인스턴스에 대한 초기화를 인스턴스를 얻는 정적 메서드 내부에 캡슐화 함으로써, 해당 싱글톤을 사용하는 입장에서는 따로 초기화에 대해 생각하지 않아도 돼.

[ㅇㅇ 1(112.163)]

인스턴스를 얻는데 사용할 메서드 내부에서 해당 인스턴스의 초기화가 스레드 세이프하게 일어날 수 있도록 구현한다면, 전역 변수와는 다르게 인스턴스 자체에 대한 race condition 발생에 대해서도 신경 쓰지 않아도 되지.

[ㅇㅇ 1(112.163)]

그러면 의존성이 숨겨지는 것이 뭐가 문제냐고 생각 할 수 있겠지. 가장 먼저 고려해야 할 점은, 과연 싱글턴 인스턴스의 수명은 언제까지 인지. 다음으론 만약 싱글턴이 다른 클래스에 의존 해야 한다면? 그럼 그 다른 클래스들도 모두 싱글턴으로 만들어줘야 하는 건가? 다른 애들이 말하듯이 많은 게임 엔진에서 싱글톤을 많이 사용해, 다만 이 경우 애초에 설계 과정에서 각 모듈에 대한 의존성에 대한 명확하게 분석을 해두고. 초기화 순서/해제 순서 모두 수동으로 관리하는 경우야

[ㅇㅇ 1(112.163)]

정리하자면 정말 인스턴스가 하나만 생성될 수 있도록 강제하고 싶다면 싱글톤 사용해도 된다, 다만 그 싱글톤에 대한 의존성을 명확하게 파악하고 추적 관리는 필수.

[ㅇㅇ 2(118.44)]

그냥 스타트함수같은 곳에서 태그나 타입검색같은거로 가져와

[익명(melon1029)]

겟컴포넌트..? 근데 난 싱글톤 좋아함

[ㅇㅇ 3(211.200)]

걍 Find 해서 가져오라고

[태보미(taebomi)]

https://youtu.be/WLDgtRNK2VE?si=z6GOrW2BAOII2gph
이거
보면 해결댐

[소닉쫄따구테일즈(dcz3xv7zgu14)]

초기:편해서 뭣도모르고씀 중기:객체지향이든 의존성복잡도때문에 최대한 안써봄 후기:편해서 그냥 씀

[ㅇㅇ 4(182.224)]

유틸리티 또는 게임씬에 하나만 존재하는것은 싱글턴으로 하는게 편하지. 그거다 의존성 관리하다가 디버깅만 힘들다. 무조건 안된다고 하는사람은 초보임. 소닉쫄따구테일즈님 고수인듯!

[익명(121.138)]

현역가면 서버 백엔드나 게임개발이나 결국 다 싱글톤 씀 스프링은 ㄹㅇ 싱글톤에 환장한 새끼고

[ㅇㅇ 5(175.119)]

vcontainer 쓰셈

[ㅇㅇ 6(220.120)]

게임 잘돌아가면 그냥 싱글톤 써