루비와 싱글턴 패턴: 잘 어울리지 않는 조합

루비에서 싱글턴 패턴을 구현하려는 시도는 여러 가지가 있으나, 모두 고유한 문제점을 안고 있습니다.

1. 표준 라이브러리 Singleton 모듈

• include Singleton으로 단일 인스턴스를 보장하지만, 상속/복제/마샬링 등 광범위한 내부 오버라이드로 인해 과도하게 복잡합니다.

2. 클래스 메서드만 사용하는 클래스

• undef_method :new로 인스턴스 생성을 막지만, 인스턴스화될 수 없는 클래스라는 철학적 모순과 상속 계층에서의 역할 문제가 있습니다.

3. 모듈 메서드만 사용하는 모듈

• 인스턴스화 불가를 이용하지만, 모듈이 믹스인될 수 있어 “쓸모없는 인스턴스”와 유사한 상황을 초래하며, 순수성 관점에서 이점이 적습니다.

4. module_function을 사용하는 모듈

• 메서드를 모듈 레벨에서 호출 가능하게 하고 믹스인 시 비공개로 만들지만, private 키워드와의 복잡한 상호작용과 비공개 메서드 호출 불가 등 혼란스러운 동작을 보입니다.

5. extend self를 사용하는 모듈

• module_function의 대안으로, 모듈 자체에 인스턴스 메서드를 확장합니다. 접근 제어가 일관되지만, 믹스인 시 모든 메서드가 대상 객체의 공개 API에 추가될 수 있습니다.

6. Object의 베어 인스턴스 활용

• Object.new 객체에 직접 메서드를 추가하여 구현하지만, inspect 시 불투명하고 RDoc과 같은 도구를 통한 문서화가 어렵습니다.

7. 직접 구현한 구조체

• Scala의 object와 유사한 명명된 단일 객체 구문을 제안하지만, 루비 언어의 1차 지원 부족으로 문서화 및 기존 Class/Module과의 일관성 문제가 있습니다.