데이터매니저가 싱글톤인데 이놈이 각종 생성자 매개변수 등에 주구장창 쓰여서
다른 매니저가 작업중 임의의 생성자를 호출하는 순간 데이터매니저도 불러야돼서 중첩호출이 되는데
이런 호출구조가 나중에 문제생길일이 있을까?
싱글톤 중첩호출이 문제라면 스태틱 중첩호출도 문제가 되나?
만약 싱글톤일때만 문제가 된다면 데이터매니저는 스태틱으로 당장 바꾸라면 바꿀수도 있지만 아직은 굳이 바꿔서 얻는 이점을 잘 모르겠어서 냅뒀는데
왜 하지말라는거임?
데이터매니저가 싱글톤인데 이놈이 각종 생성자 매개변수 등에 주구장창 쓰여서
다른 매니저가 작업중 임의의 생성자를 호출하는 순간 데이터매니저도 불러야돼서 중첩호출이 되는데
이런 호출구조가 나중에 문제생길일이 있을까?
싱글톤 중첩호출이 문제라면 스태틱 중첩호출도 문제가 되나?
만약 싱글톤일때만 문제가 된다면 데이터매니저는 스태틱으로 당장 바꾸라면 바꿀수도 있지만 아직은 굳이 바꿔서 얻는 이점을 잘 모르겠어서 냅뒀는데
왜 하지말라는거임?
싱글톤 패턴자체가 하나만 존재하는 스태틱 인스턴스를 사용하는건데 싱글톤을 스태틱으로 바꾼다는말이 무슨말이야? 싱글톤 중첩호출이 문제되는경우는 멀티쓰레딩을 쓰는게아니라면 초기화 과정에서 순환참조가 걸려서 a를 초기화하려면 b가필요함->b를초기화하려면 c가필요함->c를초기화하려면 a가필요함 이런상황만 피하면돼 - dc App
싱글톤들끼리 의존성 생기면 초기화랑 정리시에 신경써줘야 하는게 좀 피곤하긴 함..
싱글톤은 상관없는데, 싱글톤끼리 의존성 안생기게만 관리해주면 큰 문제 못겪어봤음
데이터매니저가 뭐할때 쓰는 싱글톤임? 무슨 데이터가 들어있음?
> 다른 매니저가 작업중 임의의 생성자를 호출하는 순간 데이터매니저도 불러야돼서 중첩호출이 되는데 난 이부분이 신경쓰임 이게 복잡해지면 윗댓에서 언급한 것과 같은 형식의 문제가 될 수 있음 싱글톤으로 관리하고 싶은 거라면 뭔가 그 안에서 유지하고싶은 상태가 있어서 그러는 걸텐데 데이터매니저를 특정 상태를 관찰하는 모니터 클래스나 특정 객체를 생성하는 팩토리 클래스를 생성해주는 컴포넌트매니저로 바꾸는 것은 어떰
그래서 최대한 뭔가 이런 저런 매니저를 불러서 해결하는 문제를 각 모니터 팩토리 클래스로 분리를 하셈 그럼 구조가 A 매니저가 X 를 만들기 위해 B 매니저를 부른다에서 X를 만들고 싶으면 X 팩토리를 만들고 X 팩토리가 A, B 매니저에서 필요한 값을 가져와 처리함 이런 구조로 바뀌어서 순환참조를 피하기 쉬워질거같은데
이 이상 자세한 구조는 뭔겜인질 몰라서 어케 해야댈지 몰겟음