GUI 프로그래밍을위한 Signals + Slots 모델에 대한 실질적인 대안?

현재 대부분의 GUI 툴킷은 신호 + 슬롯 모델을 사용합니다. 내가 틀리지 않았다면 누가 그것을 개척했는지는 Qt와 GTK +였습니다.

위젯 또는 그래픽 객체 (때로는 표시되지 않은 객체) 가 메인 루프 처리기로 신호 를 보냅니다 . 그런 다음 메인 루프 핸들러 는 해당 위젯 / 그래픽 객체에 할당 된 이벤트 , 콜백 또는 슬롯 을 호출 합니다. virtual개발자가 각각의 모든 메시지 자체에 대해 전체 메인 루프와 핸들러를 작성해야하는 이전의 설계와 달리, 사전 정의 된 모든 신호를 처리하기 위해 툴킷에서 이미 제공 한 기본 (및 대부분의 경우 ) 이벤트 핸들러가 있습니다. (WINAPI를 생각하십시오) 개발자는 새로운 기능을 구현하는 데 필요한 신호 만 걱정하면됩니다.

이제이 디자인은 내가 아는 한 대부분의 최신 툴킷에서 사용되고 있습니다. Qt, GTK +, FLTK 등이 있습니다. Java Swing이 있습니다. C #에는 언어 기능 (이벤트 및 대리자)도 있으며 Windows Forms는이 디자인을 위해 개발되었습니다. 실제로 지난 10 년 동안 GUI 프로그래밍을위한이 디자인은 일종의 기록되지 않은 표준이되었습니다. 생산성을 높이고 더 큰 추상화를 제공하기 때문입니다.

그러나 내 질문은 다음과 같습니다.

현대적인 GUI 프로그래밍에 평행하거나 실용적인 대안 디자인이 있습니까?

즉, 신호 + 슬롯 디자인은 도시에서 유일하게 실용적인 디자인입니까? 다른 디자인으로 GUI 프로그래밍을 수행 할 수 있습니까? 현대적인 (바람직하게는 성공하고 인기있는) GUI 툴킷이 대체 설계로 구축 되었습니까?

비록 그렇게 인기있는 것은 아니지만 , GUI에 대한 반응성 프로그래밍 , 특히 .NET Rx Framework 및 약간 더 난해한 언어 / 플랫폼의 여러 툴킷에 의해 구현되는 기능적 반응성 프로그래밍이 있습니다. 반응 형 바나나 또는 FrTime 과 같이 Haskell 및 Racket 각각에 대해

그것은 제가 가장 좋아하는 주제이며, 약 10 년 동안 ('70 ~ 86 년) 이벤트에 반응하는 객체로 구성된 GUI를 갖는 것이 올바른 방법이라고 생각했습니다.

그리고 나는 그것을 할 수있는 또 다른 방법에 발견 여기에 설명 과 소스 포지 프로젝트와 여기를 .

간단히 말해서, 객체의 문제점은 객체가 지속된다는 것입니다. 객체를 생성하기 위해 코드를 작성하는 경우 변경이 필요한 경우 점진적으로 수정하기 위해 코드를 작성해야하며 어떻게 든 메시지를주고받을 수 있습니다. 원하는 것을 페인트 한 다음 다른 것을 원한다면 다시 칠하고 이전 객체의 지속성에 대해 걱정할 필요가 없다면 다시 칠할 수 있다면 좋지 않을까요? 메시지 처리를 위해 코드를 작성하지 않아도되는 경우에도 좋지 않습니까?

그것이 그 패키지가하는 일입니다. 간단한 대화 상자의 경우 코드의 순서를 저장합니다. 동적으로 변화하는 복잡한 대화의 경우 가능합니다.

추신 : 나는 웹 브라우저 UI가 아닌 데스크탑 UI 및 원격 터미널 UI에 대해서만 이것을 수행했습니다. 나는 그것이 가능하다고 확신하지만 그것을 시도 할 기회가 없었습니다.

이에 대해 두 가지 뚜렷한 방법이 있습니다.

1. 모든 위젯에 세분화 된 구독 메커니즘 (신호 / 슬롯, 관찰자 ​​/ 관찰 가능, 이벤트 / 삭제)을 노출시키고 클라이언트 코드가 구독하고 이에 따라 조치를 취하도록하십시오.
2. 데이터의 추상화에 대해 위젯을 구축하고 클라이언트 코드가 해당 추상화를 구현하도록합니다.

두 번째 접근 방식의 예는 다음과 같습니다.

interface Action {
     void execute();
     Bool isEnabled();
     Null<String> description();//used for tooltip
}
interface LabledAction extends Action {
     String getName();
}

그리고 지금 당신은에 LabelButton대해 빌드 할 수 LabledAction있으며 클라이언트 코드는 그것을 구현하거나 사용 가능한 경우 적절한 기본 구현을 사용할 수 있습니다.

어떤 방식으로 두 번째 접근 방식은 덜 유연하지만 더 엄격합니다. 상대적으로 원자적인 수단을 통해 뷰와 모델을 연결하는 것이 아닙니다. 요구 사항에 따라 적절한 GUI를 디자인 한 다음 해당 GUI와 도메인 / 응용 프로그램 논리 사이에 어댑터를 구현합니다.

일부 제어 유형 시스템은 데이터베이스 접근 방식을 사용합니다. 각 GUI 제어는 데이터베이스에 정리되어 GUI가 항상 데이터베이스 상태를 반영합니다. DB 후크는 값이 변경 될 때 함수를 트리거하는 데 사용됩니다.