메시지 유형에 따라 다른 처리 방법은 무엇입니까?

Question

메시지 유형의 기본 클래스를 매개 변수로받는 "통지"메소드가있는 프로세스가 있습니다. 파생 된 메시지 유형을 기반으로 다른 처리를하고 싶습니다. 이것은 "프로세스"또는 메시지 유형과 비슷한 메소드를 추가하고 다형성을 사용하여 호출해야한다는 것을 의미합니까? 특정 메시지 유형마다 "알림"을 추가하는 것이 더 좋습니까?

세부 정보 : 언어는 C++입니다. 여기서는 좋은 생각이 될 것이라고 생각했기 때문에 다양한 메시지 유형에 대해 알림을받는 방법이 하나만 필요했습니다. 컨트롤러는 순수한 vitual notify (MsgBaseClass) 메서드를 지정하는 listener 클래스에서 상속받습니다. 나는 새로운 메시지 유형마다 알림을 추가 할 필요가 없기 때문에 여전히 그 생각을 좋아합니다. 그러나 컨트롤러 코드 자체에서 동적 캐스트와 같은 메시지 유형을 구분하거나 메시지 유형을 메시지에 추가하는 방법은 없습니다.

편집 : Visitor 패턴을 사용하겠습니다. 그것은 내가 알림을위한 단 하나의 메소드를 유지하도록하고, 코드에서 switch 문을 피할 수있다. "방문자"인터페이스는 다양한 파생 메시지 유형을 처리하기 위해 수신기가 필요로하는 다양한 메소드를 지정합니다. 이 메시지의 기본 클래스에 추가 할 단 하나의 메시지가 필요합니다 (이), "순수 가상 수락 (MyMessageTypeVisitor V) 파생 된 메시지 클래스 대해서 v.visit를 사용하여 구현하는 것이다.

이

내가이 정도면 생각

Answer 1

고전적인 OO 응답을 위해서는 구체적인 메시지 서브 클래스가 특정 처리를 제공하기 위해 오버라이드하는 추상 메소드를 제공해야합니다.

Dylan 및 CLisp과 같은 일부 언어 (널리 사용되지는 않음)는 문제를 아주 크게 해결하는 "일반 함수"(인자 유형에 동적으로 전달됨)를 제공합니다.

인기있는 언어에서 실행 가능한 유연한 접근법 중 하나는 Bob Uncle의 "Acyclic Visitor"디자인 패턴 http://www.objectmentor.com/resources/articles/acv.pdf입니다. 더 많은 방문자 변종에 대해서는 www.ccs.neu.edu/research/demeter/adaptive-patterns/visitor-usage/papers/plop96/variations-visitor-nordberg.ps를 참조하십시오.

Answer 2

편집 : 나는 dirkgently 좋은 지적이 있다고 생각하고 그 메시지는 어떻게 처리해야 하는지를 알지 못한다고 생각합니다. 따라서 메시지를 공장으로 사용할 수있는 방법은 좋은 생각이 아닙니다. 그래도 추상적 인 프로세스 팩토리가 좋은 해결책이라고 생각해보십시오.

추상 팩토리를 crea에 사용하십시오. 처리를 처리 할 수있는 객체, 다형성을 사용하여 호출합니다. 이 팩토리는 메시지 클래스에 직접 포함되거나 메시지 유형을 매개 변수로 받아들이고 적절한 객체를 반환하는 별도의 팩토리 클래스를 만들 수 있습니다.

class Message { 
public: 
    virtual Processor *getProcessor() = 0; 
    // other methods 
}; 

class Processor { 
public: 
    virtual void doWork() = 0; 
}; 

class MyListener : Listener { 
public: 
    void notify(Message *message); 
}; 

void MyListener::notify(Message *message) { 
    Processor *proc = message->getProcessor(); 
    proc->doWork(); 
}; 

(이 잘못된 경우 죄송합니다. 내 C++은 조금 약하지만, 나는 그것이 원칙을 설명 생각합니다.)

이 방금 각 메시지 유형에 대한 getProcessor()를 오버라이드 (override) 할 수 있도록, 그리고 것 거기에 적절한 프로세서를 만듭니다.

IMVHO, 다형성은 갈 길입니다. 내 생각 엔 처리 논리의 종류가 메시지 클래스에 속하지 않으므로 별도의 클래스로 이동해야합니다. 이 방법을 선호하는 또 다른 이유는 추가 메시지를 추가하면 알림을받는 클래스의 구조를 변경하지 않아도된다는 것입니다. 메일 유형이 하나 또는 두 개인 경우 문제가되지 않을 수 있습니다.

Answer 3

관찰자 디자인 패턴이 붙어 있습니까?

오버로드 notify은 후보로 보입니다. 관찰자 패턴은 정말 간단합니다. the Hollywood Principle을 기반으로합니다. 즉, "전화하지 마세요, 우리는 전화 할게!". 아이디어는 일련의 객체 (옵서버)를 가지고 있고 쿼리하는 대신 알려주는 것입니다. 일반 Event 데이터를 옵서버에게 전달합니다. 그것은 무엇을 해야할지를 결정하기 위해 관찰자에게 맡겨야합니다. 관찰자가 다른 이벤트에 반응하면 (예, 이벤트 계층 구조가 필요합니다) dynamic_casts이 있습니다.

Answer 4

은 당신이 뭔가를 할 수 있습니다 :

DerivedType *dt = dynamic_cast<DerivedType>(&BaseType); 
if(dt != NULL) 
{ 
    // Handle processing of DerivedType 
} 

그냥 각 처리 DerivedType에 dynamic_cast는 일을하려고합니다. null이 아닌 포인터를 얻으면 형변환하려고 시도한 타입을 받았음을 알게됩니다.