대부분의 사람들은 이미 싱글 톤 / 개요 클래스가 무엇인지 설명했습니다. 바라건대, 나는 약간 다른 관점을 제시하고 실용적인 예를 제시 할 것입니다.

싱글 톤-모든 호출 코드가 단일 변수 인스턴스를 사용하기를 원하는 경우 다음과 같은 옵션이 있습니다.

• 전역 변수-분명히 캡슐화가 없으며 전역에 연결된 대부분의 코드 … 나쁜
• 모든 정적 함수가있는 클래스-단순한 전역보다 조금 낫지 만이 디자인 결정은 여전히 ​​코드가 전역 데이터에 의존하고 나중에 변경하기가 매우 어려운 경로로 안내합니다. 또한 정적 함수 만 있으면 다형성과 같은 OO를 활용할 수 없습니다.
• 싱글 톤-클래스의 인스턴스가 하나 뿐이지 만 클래스의 실제 구현은 글로벌이라는 사실에 대해 전혀 알 필요가 없습니다. 따라서 오늘은 단일 클래스 인 클래스를 가질 수 있습니다. 내일이면 생성자를 공개하고 클라이언트가 여러 사본을 인스턴스화 할 수 있습니다. 싱글 톤을 참조하는 대부분의 클라이언트 코드는 변경 될 필요가 없으며 싱글 톤 자체의 구현은 변경 될 필요가 없습니다. 유일한 변경 사항은 클라이언트 코드가 처음에 싱글 톤 참조를 얻는 방법입니다.

모든 사악하고 나쁜 옵션 중에서 글로벌 데이터가 필요한 경우 싱글 톤은 이전 두 가지 방법 중 하나보다 훨씬 더 나은 방법입니다. 또한 내일 마음이 바뀌고 글로벌 데이터 대신 제어 역전 을 사용하기로 결정한 경우 옵션을 열어 둘 수 있습니다 .

그렇다면 싱글 톤을 어디에 사용 하시겠습니까? 몇 가지 예는 다음과 같습니다.

• 로깅-전체 프로세스가 단일 로그를 가지도록하려면 로그 오브젝트를 작성하고 어디에서나 전달할 수 있습니다. 그러나 100,000k 라인의 레거시 애플리케이션 코드가 있다면 어떨까요? 그들 모두를 수정? 또는 다음을 간단히 소개하고 원하는 곳 어디에서나 사용할 수 있습니다.

  CLog::GetInstance().write( "my log message goes here" );

• 서버 연결 캐시-이것은 우리 응용 프로그램에서 소개해야 할 일이었습니다. 우리의 코드베이스는 코드가 많았으며, 필요할 때마다 서버에 연결하는 데 사용되었습니다. 네트워크에 대기 시간이없는 한 대부분의 경우 정상입니다. 우리는 솔루션이 필요했고 10 년 된 애플리케이션의 재 설계는 실제로 테이블에 없었습니다. 단일 CServerConnectionManager를 작성했습니다. 그런 다음 코드를 검색하여 CoCreateInstanceWithAuth 호출을 클래스를 호출 한 동일한 서명 호출로 대체했습니다. 이제 첫 번째 시도 후 연결이 캐시되고 나머지 “연결”시도는 즉시 이루어졌습니다. 어떤 사람들은 싱글 톤이 악하다고 말합니다. 나는 그들이 내 엉덩이를 구했다고 말합니다.

• 디버깅을 위해 전역 실행 객체 테이블이 종종 유용하다는 것을 알았습니다. 우리가 추적하고 싶은 수업이 있습니다. 그들은 모두 같은 기본 클래스에서 파생됩니다. 인스턴스화하는 동안 객체 테이블 싱글 톤을 호출하고 자신을 등록합니다. 그들이 파괴되면, 그들은 등록을 해제합니다. 모든 컴퓨터로 걸어가 프로세스에 연결하고 실행중인 개체 목록을 만들 수 있습니다. 지난 10 년 동안 제품에 들어 왔으며 2 개의 “글로벌”객체 테이블이 필요하다고 생각한 적이 없습니다.

• 정규식에 의존하는 비교적 복잡한 문자열 파서 유틸리티 클래스가 있습니다. 정규식 클래스는 일치를 수행하기 전에 초기화해야합니다. 구문 분석 문자열을 기반으로 FSM 을 생성 할 때이므로 초기화 비용이 다소 비쌉니다 . 그러나 그 이후에는 일단 빌드 된 FSM이 변경되지 않기 때문에 100 개의 스레드가 정규식 클래스에 안전하게 액세스 할 수 있습니다. 이 파서 클래스는 내부적으로 싱글 톤을 사용하여이 초기화가 한 번만 발생하도록합니다. 이는 성능을 크게 향상 시켰으며 “악한 싱글 톤”으로 인한 문제는 발생하지 않았습니다.

이 모든 것을 말했듯이 싱글 톤을 언제 어디서 사용할지 명심해야합니다. 10 번 중 9 번이 더 나은 솔루션이 있으며 반드시 대신 사용해야합니다. 그러나 싱글 톤이 절대적으로 올바른 디자인 선택 인 경우가 있습니다.

다음 주제 … 인터페이스와 추상 클래스. 먼저 다른 사람들이 언급했듯이 인터페이스는 추상 클래스이지만 구현이 전혀 없다는 것을 강요함으로써 그 이상입니다. 일부 언어에서 interface 키워드는 언어의 일부입니다. C ++에서는 단순히 추상 클래스를 사용합니다. Microsoft VC ++는이를 내부적으로 정의하기 위해 한 단계를 밟았습니다.

typedef struct interface;

… 그래서 여전히 인터페이스 키워드를 사용할 수 있지만 (실제 키워드로 강조 표시 될 수도 있음) 실제 컴파일러에 관한 한 그것은 단지 구조체입니다.

그래서 이것을 어디에서 사용 하시겠습니까? 실행중인 객체 테이블의 예로 돌아가 보겠습니다. 기본 수업이 있다고 가정 해 봅시다.

가상 무효 인쇄 () = 0;

추상 수업이 있습니다. 런타임 객체 테이블을 사용하는 클래스는 모두 동일한 기본 클래스에서 파생됩니다. 기본 클래스에는 등록 / 등록 취소를위한 공통 코드가 포함되어 있습니다. 그러나 자체적으로 인스턴스화되지는 않습니다. 이제 클래스 (예 : 요청, 리스너, 클라이언트 연결 객체 …)를 파생시킬 수 있습니다. 각 클래스는 print ()를 구현하여 프로세스에 연결하고 요청할 때 실행중인 항목을 각 객체가 자체 상태로보고합니다.

추상 클래스 / 인터페이스의 예는 셀 수없이 많으며 싱글 톤을 사용할 때보 다 훨씬 더 자주 사용하거나 사용해야합니다. 간단히 말해서 기본 유형으로 작동하고 실제 구현과 관련이없는 코드를 작성할 수 있습니다. 이를 통해 너무 많은 코드를 변경하지 않고도 나중에 구현을 수정할 수 있습니다.

또 다른 예가 있습니다. 로거 CLog를 구현하는 클래스가 있다고 가정 해 봅시다. 이 클래스는 로컬 디스크의 파일에 씁니다. 레거시 100,000 줄의 코드에서이 클래스를 사용하기 시작합니다. 여기 저기. 인생은 누군가가 말할 때까지 좋습니다. 파일 대신 데이터베이스에 씁니다. 이제 새 클래스를 만들고 CDbLog라고 부르고 데이터베이스에 씁니다. 100,000 줄을 통과하고 CLog에서 CDbLog로 모든 것을 변경하는 번거 로움을 이미징 할 수 있습니까? 대안으로, 나는 가질 수 있습니다 :

interface ILogger {
    virtual void write( const char* format, ... ) = 0;
};

class CLog : public ILogger { ... };

class CDbLog : public ILogger { ... };

class CLogFactory {
    ILogger* GetLog();
};

모든 코드가 ILogger 인터페이스를 사용하고 있다면 변경해야 할 것은 CLogFactory :: GetLog ()의 내부 구현입니다. 나머지 코드는 손가락을 떼지 않아도 자동으로 작동합니다.

인터페이스와 우수한 OO 디자인에 대한 자세한 내용을 보려면 C # 의 Uncle Bob의 민첩한 원칙, 패턴 및 실습을 강력히 권장 합니다. 이 책은 추상화를 사용하고 모든 것에 대한 명확한 언어 설명을 제공하는 예제들로 가득 차 있습니다.

답변

function foo(objs):
    for obj in objs:
        obj.printToScreen()

class HappyWidget:
    def printToScreen(self):
        print "I am a happy widget"

class SadWidget:
    def printToScreen(self):
        print "I am a sad widget"

void foo( Printable *objs[], int n){ //Please correctme if I messed up on the type signature
    for(int i=0; i<n; i++){
        objs[i]->printToScreen();
    }
}

Persister* prst = new CsvPersister();

Persister* prst = new DbPersister();