싱글톤(singleton)의 단점
1. parameter를 넣을 수가 없다.
Class.One, Class.Current, Class.Instance 이런 식으로 참조하기 때문에 parameter를 넣어서 객체 생성을 할 수가 없다.
근데 사실 이건 별로 문제가 안 된다. 내가 죽을 때까지 이 클래스에 parameter가 있는 constructor를 만들지 않겠노라고 다짐하면 된다. 아니면 나중에 리팩토링하면서 피똥 싸거나.
2. 객체의 흐름을 따라가기 어렵다.
싱글톤의 가장 치명적인 문제점이라고 생각한다.
여기저기에서 마구마구 참조하기 때문에 이 객체가 어디에서 어디로 오는지에 대한 흐름이 전혀 보이지 않는다.
참조하는 곳이 적다고 해도, 이미 전 세계 언제 어디서나 이 클래스의 싱글톤을 참조해서 가져올 수 있다는 가능성이 열려있다는 것 자체가 프로그래밍할 때 스트레스를 준다.
무엇보다, 객체가 어디서 처음 생성되는지를 알 수가 없다. 이걸 알아내려면 프로그램 진입점부터 차근차근 살펴봐야 한다.
싱글턴 패턴
/ 디자인 패턴들 / 생성 패턴 싱글턴 패턴 다음 이름으로도 불립니다: Singleton 의도 싱글턴은 클래스에 인스턴스가 하나만 있도록 하면서 이 인스턴스에 대한 전역 접근(액세스) 지점을 제공하
refactoring.guru
refactoring guru에서도 해당 문제점을 설명하고 있다. 싱글턴의 문제점은 기본적으로 전역 변수의 문제점을 상속받을 수밖에 없다.
3. 멀티스레딩에서 싱글톤을 쓰려면 mutex lock을 걸어야 한다. 나중에 성능 이슈가 생길 지도 모르는 일이지.
싱글톤이 아닌 걸 싱글톤으로 만드는 건 쉽다.
근데 싱글톤을 싱글톤이 아니게 만드는 건 어렵다.
왜냐하면 코드 어딘가에 객체 생성 코드를 만들고,
싱글톤을 참조하는 모든 클래스들에 객체를 일일히 전달해줘야 하기 때문이다.
싱글톤은 진짜 꼭 필요할 때만 신중하게 써야 한다.
그럼 싱글톤 안 쓰면 뭐 어떻게 해야 하나?
그냥 처음부터 객체 하나 뙇 만들고 그걸 여러 클래스에 전달하는 방식으로 해야 한다.
이렇게 하면 엄청 불편하고 시간도 오래 걸리지만, 미래에 대한 투자라고 생각하자.
오늘도 나는 과거의 나를 원망하며 코딩을 한다.
왜 굳이 이걸 싱글톤으로 짠 거냐!
'잡담, 뻘글' 카테고리의 다른 글
| AI도 고통을 느끼지 않을까. (0) | 2025.02.12 |
|---|---|
| 나는 영원히 존재할까? (0) | 2025.02.11 |
| Quiz: File Vulnerability (0) | 2025.02.01 |
| Apple 계정 비밀번호도 털렸다. (0) | 2025.01.06 |
| 세트제는 공정한가? (0) | 2024.12.27 |