[🐣질문] 싱글톤 패턴의 단점에 대한 질문입니다.

[O-pera(wdg2461)]

제가 지식 공부를 위해서 찾은 것들 중 싱글톤의 남용을 지양해야하는 이유에 대해서입니다.

싱글톤의 다양한 단점 중 제가 이해 가능한 것들은 SOLID원칙인 OCP, DIP에 위배되는 것입니다.

OCP의 경우, 

1. 싱글톤이 하나의 인스턴스에서 데이터를 관리하면서 다양한 클래스에게 데이터를 제공하기 때문에

결합도가 높아져 싱글톤 객체에서 수정 시 참조 중인 다른 클래스에서도 수정이 필요할 수 있기 때문이다.

2. 확장에는 개방(Open)되고, 수정에는 폐쇠(Close)인 만큼 싱글톤 객체는 자기 자신을 수정해야하기 때문에 OCP에 위배된다

DIP의 경우

1. DIP는 자주 수정될 가능성이 있는 구체 클래스 대신 추상클래스나 인터페이스를 의존하는 원칙인데

싱글톤의 경우 구체 클래스인 자기자신을 클래스 내부에서 new를 통해 동적할당하여 사용하기 때문에 DIP에 위배된다.

DIP의 경우는 제가 정리한게 맞는지 모르겠습니다.

OCP의 경우는 둘 중 어느게 맞는지, 맞는게 있긴 한건지 모르겠습니다 ㅠ

고수분들의 의견 부탁드립니다!

[익명(175.125)]

이거 나도 궁금하네

[O-pera(wdg2461)]

제가 싱글톤에 대해서 자세히 아는 것도 아니고 직접 사용해본 것도 이렇게하면 된다만 배워서 너무 궁금합니다... 이런건 못참는 성격이라

[키무치(beast04601)]

근데 게임 개발하면 싱글톤은 걍 남발하지 않나? 게임 매니저 인풋 매니저 등등 무슨무슨 매니저는 거즘 다 싱글톤이자너 ㅋㅋ

[O-pera(wdg2461)]

네...ㅋㅋㅋ 저도 그냥 남발할까 하다가 어제 공부 잘하는 친구가 싱글톤 남용하면 안된다 했는데 이유는 모르는것 같아서 궁금해서요..ㅋㅋ

[연어(smosal)]

이론적인건 사실 말로들어선 안와닿지만, 직접 써보면서 무언가를 만들고 리팩토링해보다 보면 몸으로 느껴질겁니다. 아 이게 이래서사람들이 줮같다하는구나... 이론적으로 무슨 원칙에 어긋나네.. 하던소리가 결국 이런상황을 야기하는걸 말하던거구나..하는

[O-pera(wdg2461)]

Aㅏ.... 리팩토링을 할 수준까지는 아직 안되서.... 조금 더 개발해보면서 나중에야 알 것 같네요 ㅠ

[연어(smosal)]

글구 싱글톤없으면 뭐못만드냐~하면 꼭그런것도아니고, 전 아에 애초에 안쓰고함. 그럼 싱글톤은 백해무익 알필요도없는거냐~하면 그건아니지만 전안쓸수있으면 안쓰려고하고.. 안써도 못할건없음

[O-pera(wdg2461)]

그럼 데이터베이스 저장하는 객체는 어떻게 만드시나요?? 저는 인벤토리, 아이템 데이터베이스, 게임매니저, UI매니저 이 정도 까지는 써야할 것 같은데

[연어(smosal)]

저는 ScriptableObject활용해서 쓰고있는데, 유니티 공식 오픈프로젝트 chopchop 이라고있음. 고거랑 비슷한 방식으로 만들어쓰고있음니다. 나중에 공부좀하시다 이제머 딴사람들만든거나 이런거저런거 보면서 배우시고싶으실때쯤 유니티 공식유튜브랑 그거 깃헙에있는거 참고하면서 배우면 도움딀듯

[연어(smosal)]

대충 와닿는 쉬운얘기로 풀어보자면. 딱하나의 예외를둬서 게만 특별대우를하며 모두가 걔랑 연관된 뭔가를하는 프로그램을 만들었다면, 어떤 일부분 수정이 필요할 때 이걸고치면 쟤도고쳐야하고, 근데 걜고치면 걔한태영향받는 딴애들도 고쳐야하고.. 난 꼴랑 0.1정도만 고치고싶은데 일이 눈덩이처럼 불어나게 서로 얼키설키 지저분한 꼴이되어서 처음에의도한대로 깔끔한 모습이 아닌, 깝깝한꼴이되곤함

[O-pera(wdg2461)]

싱글톤 내부 계속 수정하면서 OCP DIP 전부 다 위배하셨나보군요... 우욱

[연어(smosal)]

전 뉴비때 공부하면서 싱글턴 안배운상태로 감으로 그런구조를 만들어 쓰며 고생해본적있음. 나중에알고보니 그게 싱글턴이더라구요. 디자인패턴이란게.. 어캐보면 거창하지만, 사실 까고보면 사람들 생각 거기서 거기니깐.. 삽질하면서 맛봐봤었음.

[연어(smosal)]

찾아보면 아시겠지만 싱글톤의 무슨 단점을 극복한~ 개선한~ 뭔구조~ 해서 많아요. 근데 완벽한 솔루션이있었음 다들 그거 쓰고있었겠죵. 다결국 근본적인 문제자체는 어쩔수없이 가지고있어어... 걍 전 나중에 큰문제 겪기싫어서 아에 그런거 거르기로 생각하고 만듬. 그래도 알고는 있는게 좋다고생각함. 뭐... 어디에나 맞는 완벽한솔루션이란게있는것도아니고, 사람마다의견은다르니까.. 직접 배워보고 느껴보세용

[O-pera(wdg2461)]

감사합니다 패턴들 직접 익혀보면서 쓸 기능 안쓸 기능 걸러봐야겠네여

[익명(61.97)]

싱글톤 패턴(lazy initialize) 뿐만 아니라 그냥 정적객체 처럼 활용되는 모든 객체에 해당함. 일단 알 수도 있겠지만, 싱글톤 패턴으로 남용되는 것같은 객체들 (게임으로 예시로 들면 모두들 한 번은 사용해본 Game Manager)은 코드 분량으로 보면 고수준 모듈처럼 보일 수 있는데 비즈니스 모델상 저수준 모듈임. GameManager가 OCP를 위반하는 건 GameManager가 어떤 일을 하는지에 따라 다를 수도 있는데(사실 이름에서 부터 이미 유추하기가 어려움. 이것도 문제점임) GameManager에 새로운 기능을 추가하고 싶으면 말 그대로 GameManager를 수정해야하는 경우가 많을거임. 상속관계는 커녕 사실상 sealed된 클래스라 봐도 될거고..

[익명(61.97)]

쨋든 주로 GameManager에 함수를 추가하거나 구현 내용을 수정하게 되면서 발생하는 사이드 이펙트가 문제임. 본문에 쓴 1, 2중에서는 2가 좀 더 적절한 내용인듯. 1은 DIP에 더 가까운 내용같음.

[익명(61.97)]

DIP의 경우 위에 이미 말해버렸지만 GameManager는 게임 로직상 저수준 모듈이기 때문에 게임 로직상 고수준의 모듈이 의존하게 만들기 때문에 위배되는거임. OCP, DIP의 해결방법은 말한것처럼 인터페이스나 추상 클래스 등 저수준 코드의 변경에 의존하지 않는 방법으로 우회하는 방법인데 이렇게 GameManager를 쪼개다보면 어느 순간 GameManager라는 객체가 필요없어짐을 알아챌수있는거지 ㅋㅋㅋ

[익명(61.97)]

SOLID원칙 자체가 어떻게보면 비슷한 내용이 많아서 헷갈릴수 있음.. 사실 나도 너무 올만에 봐서 내용 써놓고 보니까 맞는 말인지 잘 몰겠다 ㅋㅋㅋ 그리고 남용하면 안되는건 맞지만 유동적으로 상황보면서 쓰는게 훨신 문제를 깔끔하게 해결하는 방법일수도 있음.. 지금까지 개발해보고 느낀건데 싱글톤 객체가 없는 프로그래밍도 가능할거라고 보기는 함.. 좀 불편할 뿐이고

[익명(61.97)]

메모장에 쓸 말 정리하고 올리고 보니 댓글이 엄청 달려있는데 Unity의 Input, Time 객체같은거도 비슷한 맥락임. 얘네도 싱글톤 객체와 비슷한 문제점을 공유하고 있고, 고수준의 객체들이 다수 이러한 객체에 의존하고 있을텐데 어느날 유니티 엔진 업데이트를 진행해서 Input이 키 입력을 처리하는 매커닉이 조금 변경되고 Time이 델타타임을 다른 방법으로 도출해내게 되서 게임 플레이가 바뀌게 된다면 (미세하게라도 바뀌면 안 되는것이 개발 스펙이었다면) 큰일이 나는거고.. 다만 이러한 이유로 Input, Time과같은 객체들은 변경에 매우 보수적인 상태인데 비해 GameManager같은 객체는 게임 기능이 추가되거나 아니면 그냥 게임 개발 중에 필연적으로 코드 변경이 잦은게 문제임

[익명(61.97)]

'인벤토리, 아이템 데이터베이스, 게임매니저, UI매니저' 요런건 있을 법함. 다만 게임 매니저랑 UI 매니저는 정확히 어떤일을 할지 명확하게 구분해줘야할 듯 함 (ex: UI매니저 → 팝업 매니저, android os에서 back key입력을 순차적으로 처리해주는 객체, UI 공간과 월드 공간상의 좌표 변환을 도와주는 객체 등..) solid원칙을 지켜서 개발한다면 인벤토리나 아이템 데이터베이스는 특정한 키 값을 기반으로 아이템을 가져올 수 있는 인터페이스들로 구현해서 아이템 데이터베이스가 로컬 기반에서 서버로 옮겨지거나 인벤토리가 캐릭터 인벤토리 뿐만 아니라 창고 인벤토리도 생기고 다양한 기능으로 확장 되어도 아이템을 정상적으로 가져오는것이 보장되어야하고

[익명(61.97)]

물론 요런거 지키면서 만드는 프로젝트는 진짜 거의 없고... 있다고 해도 사실상 개발 기간도 늘기도 하고. 계속 얘기한 것처럼 유도리 있게 개발하는게 좋음 ㅇㅇ 젤 안 좋은게 이런거 지켜야할거같아서 처음부터 각잡고 구조 잡고 개발하는거 일듯.

[O-pera(wdg2461)]

와.. .진짜 감사합니다 읽으면서 무슨 얘긴지 다 이해해버렸네요 확실히 다른 댓분들 얘기대로 짜보면서도 굳이 필요한 기능인가 싶었는데 설명도 다해주시고 ㄷㄷ 진심으로 감사합니다!