2011-02-12 4 views
5

안녕하세요.
Service Locator 패턴에 대해 here을 읽은 후에 정적 멤버 만있는 클래스가 실제로 갈 길이 멀거나 정상적인 C와 같은 인터레이스가 더 적절하지 않은 것으로 생각됩니다. 나는 그들이 심지어 필요하지 않을 때 항상 class 키워드 주위에 던지는 사람들을 만난다. 링크 된 페이지에서 가져온 정적 멤버 클래스와
예 : 여기정적 멤버 클래스와 일반 c와 유사한 인터페이스

class Locator 
{ 
public: 
    static IAudio* GetAudio() { return service_; } 

    static void Register(IAudio* service) 
    { 
     service_ = service; 
    } 

private: 
    static IAudio* service_; 
}; 

하나가 너무 그것을 할 수있는 방법 :

// in .h 
namespace Locator{ 
    IAudio* GetAudio(); 
    void Register(IAudio* service); 
} 

// in .cpp 
namespace Locator{ 
    namespace { 
     IAudio* service_; 
    } 

    IAudio* GetAudio() { 
     return service_; 
    } 
    void Register(IAudio* service) { 
     service_ = service; 
    } 
} 

두 예제는 Locator::GetAudio()Locator::Register(...)와 정확히 같은 방식으로 호출 할 수 있습니다. 위의 것 중 하나가 다른 것보다 우수합니까? 그들은 같은가요? 이것을 달성하는 더 좋은 방법이 있습니까? 아니면 개인적인 취향에 관한 것입니까? 어떤 도움을 주셔서 감사합니다. :)

+0

이것은 끔찍한 패턴입니다. 나는 이와 같은 전역 변수를 추천하는 사이트의 조언을 듣지 않을 것이다. – Puppy

+0

@Xeo : 실제 질문 : 인스턴스 별 데이터를 정기적으로 제공 할 수있는 경우 왜 전역 상태를 사용합니까? –

+0

@Matthieu : 그러면 모든 로케이터 인스턴스에 오디오 인터페이스를 등록해야합니다. 아니면 처음에 왜 그런 위치 탐지기가 필요한지를 의미 했습니까? – Xeo

답변

3

네임 스페이스와 귀하의 제안은 유지 보수에 약간의 약점을 가지고 - 당신이 어떤 이유로 인터페이스를 변경해야하는 경우, 당신은 인터페이스 (.h) 및 구현 (.cpp)을 모두 변경해야 할, 또는 일치하지 않을 수 링크 할 때까지 탐지되지 않습니다. class을 사용하는 경우 컴파일러은 많은 매개 변수 불일치와 같은 오류를 감지 할 수 있습니다.

반면에 .cpp 파일에만 구현 (service_)이 나타나기 때문에 로케이터에 의존하는 코드의 재 컴파일을 강요하지 않으면 서 로케이터의 개인 구현을 변경할 수 있습니다. 공통 클래스 기반 패턴은 동일한 캡슐화를 제공 할 수 있습니다.

이들은 사소한 차이점이 있습니다. 함수를 포함하는 공용 네임 스페이스는 정적 멤버 함수 만 가진 클래스와 거의 동일합니다.

+0

함수의 네임 스페이스는 익명이 아니므로 변수의 네임 스페이스를 의미한다고 생각합니까? – Xeo

+0

죄송합니다, 나는 공용'Locator' 네임 스페이스를 의미했습니다. 답변이 수정되었습니다. –

0

클래스 인터페이스를 사용하는 한 가지 좋은 이유는 일관성입니다.

종종 Locator 클래스에서 공유 데이터의 구현 또는 하위 클래스 사용이있을 것입니다. 따라서 (일부 구현은 서비스를 확장하거나 전문화 할 수 있기 때문에) 정적 데이터에 네임 스페이스와 클래스를 결합하는 것이 아니라 코드베이스에서 하나의 접근 방식을 사용하는 것이 더 바람직합니다.

많은 사람들이 정적 데이터를 다루는 것을 좋아하지 않습니다. 위의 예제의 일부 문제는 스레드 안전성, 소유권 및 데이터 수명입니다. 데이터 및 구현은 파일 범위가 아닌 클래스 범위로 제한되는 경우 유지 관리가 더 쉽습니다. 이러한 문제는 프로그램의 복잡성이 커짐에 따라 커집니다. 게시 한 예는 매우 간단합니다.

네임 스페이스 레이블/별칭은 형식/typedefs/템플릿 매개 변수와 비교하여 전달하기가 더 어렵습니다. 이는 인터페이스가 유사하고 많은 양의 일반 프로그래밍을 사용하거나 단순히 테스트를 구현하려는 경우에 유용합니다.