모듈 식 UI 및 이벤트 관리를위한 패턴

내 응용 프로그램에는 UI 구성 요소와 이벤트 관리에 대해 서로 다른 클래스가 있습니다.모듈 식 UI 및 이벤트 관리를위한 패턴

초기 생각은 Window와 Frames에 대해 별도의 클래스를 갖는 것이고 Window는 Frames의 구성을 가질 것입니다.

그리고 창이나 프레임/컨트롤 수준에서 발생하는 이벤트를 생성하고 위임 할 수있는 단일 항목이 있어야합니다.

그러나이 패턴의 패턴을 결론 지을 수는 없습니다.

현재 개별 UI 프레임/컨트롤에 직접 연결된 별도의 이벤트 처리기가 있습니다.

이 사용 사례에 적합한 패턴을 선택하는 데 도움이되도록 안내해주세요.

출처

2013-02-16 rock_win

EventAggregator 패턴을 사용해야합니다. 그것은 모듈을 서로 분리시킵니다. 이런 식으로 모듈은 다른 모듈을 알 필요가 없습니다.

here 같은 주제에 대한 다른 (더 자세한) 대답을 볼 수 있습니다.

너무 느슨한 커플 링이 필요하지 않은 경우 (예 : 모듈에 서로 참조가 있음) Observer pattern을 살펴보아야합니다. 분산 이벤트 처리 메커니즘을 구현하는 또 다른 방법입니다.

출처

2013-02-17 14:01:32 Hasan

이 패턴을 선택하는 것이 제 의견이지만, 명령 패턴의 확장이 더 많아졌습니다. 명령 패턴이 가져 오는 프로토콜의 엄격한 집행이없는 구성 요소의 동화가 발생했습니다. –

정확히! 추가 정보로서 QT API 문서 [여기] (http://qt-project.org/doc/qt-4.8/signalsandslots.html)와 [article] (http : //www.elpauer .org/stuff/a_deeper_look_at_signals_and_slots.pdf)는 분산 이벤트 처리의 또 다른 좋은 구현으로 옵저버 패턴을 기반으로하는 신호 슬롯 메커니즘을 설명합니다. – Hasan

찾고있는 것은 Command 패턴입니다. 명령 패턴은 기본적으로 요청/메시지를 완전한 객체로 캡슐화하여 메시지를 요청하는 객체가 궁극적으로 요청을 처리 할 객체에 대해 알 필요가 없도록합니다. 예를 들어 이벤트를 내보낼 수있는 메뉴 항목, 버튼 등이 있습니다. 기본적으로 이러한 요소를 코딩 할 때 누가 이러한 이벤트를 처리 할 것인지 알지 못합니다 (이벤트를 처리 할 UI 프레임 워크를 개발하고 있다고 가정합니다). 따라서 기본적으로 Command 클래스의 이벤트 수신자 정보를 인코딩하고 실제 수신자에 대한 참조를 갖습니다. 또한 도메인 특정 코드를 기본적으로 호출하는 execute 메소드가 있습니다. CopyCommand, PasteCommand 등과 같은 특정 요청을 처리 할 Command 클래스의 다양한 하위 클래스가 있습니다.

abstract class Command { 
    private Receiver receiver; 
    public void setReceiver(Rceceiver receiver){ 
    this.receiver = receiver; 
    } 

    public Rceiver getReceiver(){ 
    return this.receiver; 
    } 

    abstract execute(); 
}

는 기본적으로 지금은 setCommand API를 사용하여 개별 UI 구성 요소와 명령을 설정할 수 있습니다. UI 구성 요소는 기본 명령에 위임합니다.

class Button { 

private Command command; 

public void setCommand(Command command){ 
this.command = command; 
} 

public void onClick(){ 
    command.execute(); 
    } 
}

자세한 내용은 Gof 북의 명령 패턴을 참조하십시오.

출처

2013-02-17 16:05:01 Geek

모듈 식 UI 및 이벤트 관리를위한 패턴

답변

관련 문제