[💬] 싱글턴의 좃같음과 대안

[익명(121.181)]

싱글턴 자체는 나쁜게 아님.
근데 어리굴젓 인붕이들이 다음과 같은 코드를 쓸 때 문제가 됨.
Hero.DoDamage(damageManager.instancr.calcDamage(Monstermanager.instance.Getmonster( Hero.Target)))...
이런식으로 짜면
싱글턴이 싱글턴을 참조하는 순간
유지보수가 불가능한 코드가 태어난다고 보면 된다.
나중에 하나 들어내거나 바꾸려면 줄줄이 이어져있어서 싹 다 딸려나오지.
싱글턴이 싱글턴을 참조하는 일만 줄어들어도 싱글턴 자체의 해악은 확 줄어듬.

그리고 만약(솔직히 하는 놈 못봤지만) 테스트 코드 작성 하려면 싱글턴은 완전 논외가 됨.
애초에 스태틱 클래스랑 같은넘이라 테스트 할 때 마다 초기화 해줘야 하는 등 테스트를 쓰기 어렵게 만듬.

그러면 대안은 뭐냐?
글쎄... 그건 캐바캐일텐데
내 경우에는 DI를 쓰고있음.
의존성 주입을 통해 의존성을 찾아쓰는게 아니라 제공받는것이지.
monsterManager 의 instance를 찾는게 아니라
IMonsterInfoProvider 인터페이스를 충족하는
실제 클래스와 모킹 클래스를 만들어서
테스트 할 때는 모킹으로 인젝션 해주고 실겜에서는 실 클래스로 인젝션 해주던가 하는 식으로
의존성을 분리하고 유지보수를 용이하게 하고 있음.
zenject를 쓰는 중.

근데 본인이 인터페이스 안 쓰고 개발한다거나
겜 빠르게 출시하는게 목적이면
그냥 싱글턴 써서 빠르게 만드는게 낫겠지.
여츤 싱글턴이 다른 싱글턴을 호출하지만 마.
그러면 그건 분열된 자아 패턴이라고
거대한 하나의 클래스가 되어버리까
나중에 돈 벌리기 시작할때 뭐 하나 고치거나 추가하려면
유지보수 비용으로 다 빠진다.
무엇보다 돈 벌 타이밍에 노를 저을 수 없다는게 크다.
코드에 공 들이는게 난 결국은 이득이라 생각해.

그리고 이런글 싸면 얼마나 버는데 그딴소리 하냐 할 것 같기는 한데
구체적으로는 못 밝히겠고 내년에는 법인전환 고려중이라고만 하겠음. (세금 의료보험 다 털리는중 ㅅㅂ)

싱글벙글턴 밖에 모른다면
그걸 써서 출시하는게 옳고
유지보수에 데여봤다면
DI도 고려해 봐.

[익명(59.13)]

테스트는 cleanup만 만들면 되긴 하는데 ㅈㄴ 귀찮

[익명(59.5)]

근데 싱글톤으로 만들 수 밖에 없는게 어떤게 있음? 나는 솔직히 배우긴 했는데 굳이 왜 써먹어야 하는지 아직도 이해를 못하겠어. 결국 협업을 하다보니 다른 팀원을 못믿어서 쓰는거 아님?

[익명(222.239)]

너 만 36세 넘는 틀딱이구나 ㅋㅋㅋㅋ

[익명(121.181)]

바지사장 마렵다 ㅅㅂㅌ

[익명(124.57)]

참조할때 싱글톤만큼 그리운게 없는데 유지보수할때는 제일 죽여버리고싶음 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ