GUIプログラミングの信号+スロットモデルの実用的な代替手段はありますか？

今日のGUIツールキットの大部分は、Signals + Slotsモデルを使用しています。それを開拓したのは、QtとGTK +でした。

ご存知のように、ウィジェットまたはグラフィカルオブジェクト（場合によっては表示されないものも）がメインループハンドラーに信号を送信します。次に、メインループハンドラーは、そのウィジェット/グラフィカルオブジェクトに割り当てられたイベント、コールバック、またはスロットを呼び出します。通常、virtualすべての事前定義された信号を処理するために、ツールキットによってすでに提供されているデフォルト（およびほとんどの場合）のイベントハンドラーがあります。そのため、開発者がすべてのメッセージに対してメインループ全体とハンドラー全体を記述する必要がありました。 （WINAPIを考えてください）、開発者は新機能を実装するために必要な信号についてのみ心配する必要があります。

現在、私が知る限り、このデザインはほとんどの最新のツールキットで使用されています。Qt、GTK +、FLTKなどがあります。JavaSwingがあります。C＃には言語機能（イベントとデリゲート）さえあり、Windowsフォームはこの設計で開発されました。実際、過去10年間で、このGUIプログラミングの設計は、一種の未記述の標準になりました。それは生産性を高め、より優れた抽象化を提供するためです。

しかし、私の質問は：

現代のGUIプログラミングにとって並列または実用的な代替設計はありますか？

つまり、Signals + Slotsデザインは、町で唯一の実用的なデザインですか？他のデザインでGUIプログラミングを実行することは可能ですか？代替設計に基づいて構築された最新の（できれば成功し、人気のある）GUIツールキットはありますか？

私はそれをすべて呼び出すことはありませんが、というの人気を、常にある反応性プログラミング GUIの、特に官能性反応性プログラミングによって、例えば、実装され、.NET FrameworkのRxのやや難解な言語/プラットフォームにいくつかのツールキットによってだけでなく、 、HaskellとRacketの場合はそれぞれ、active -bananaまたはFrTimeと同様です。

これは私のお気に入りのテーマであり、約10年間（70年代から86年間）、イベントに応答するオブジェクトで構成されるGUIを持つことは、それを行うための正しい方法だと思いました。

それから私はここで説明されているそれを行う別の方法に出くわしました、そしてここに sourceforgeプロジェクトがありました。

簡単に言えば、オブジェクトの問題はオブジェクトが存続することであり、オブジェクトを作成するコードを作成する場合、変更が必要な場合にオブジェクトを段階的に変更するコードを作成し、何らかの方法でオブジェクトとの間でメッセージを取得する必要があります。必要なものだけをペイントし、別のものが必要な場合は再ペイントでき、以前のオブジェクトの永続性について心配する必要がないとしたら、すばらしいと思いませんか。メッセージ処理のためのコードを記述する必要がまったくなかったとしたら、それはすべて内部で行われるので、すばらしいことではないでしょうか。

それがそのパッケージが行うことです。単純なダイアログの場合、コードを大幅に節約できます。動的に変化する複雑なダイアログの場合、それが可能になります。

PS私はこれをデスクトップUIとリモートターミナルUIに対してのみ行っており、WebブラウザーUIに対しては行っていません。それは可能だと確信していますが、試す機会がありませんでした。

これには2つの方法があります。

1. すべてのウィジェットがきめ細かいサブスクライブメカニズム（シグナル/スロット、オブザーバー/オブザーバブル、イベント/デリゲート）を公開し、クライアントコードがサブスクライブしてそれに応じてアクションを実行するようにします。
2. ウィジェットが提示するデータの抽象化に対してウィジェットを構築し、クライアントコードにその抽象化を実装させます。

2番目のアプローチの例を次に示します。

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

そして今、あなたはLabelButtonに対してを構築できLabledAction、クライアントコードはそれを実装するか、利用可能で適切であれば、いくつかの一般的なデフォルト実装を使用できます。

ある意味で、2番目のアプローチは柔軟性が低く、より厳格です。どういうわけか、比較的アトミックな方法でビューとモデルを結び付けるだけではありません。要件に基づいて適切なGUIを設計し、そのGUIとドメイン/アプリケーションロジックの間にアダプターを実装します。

いくつかのコントロールタイプシステムはデータベースアプローチを使用しています。各GUIコントロールはデータベースに保存されているファイルにリンクされているため、Guiは常にデータベースの状態を反映しています。DBフックは、値が変更されたときに関数をトリガーするために使用されます。