あのイベントが発生してから、そのイベントが終了したら発生するイベントが終了したらウィンドウ閉じて、その間は別のイベントはブロックして/発生しないようにして、とかもうわけわかんない。プログラミングをしたこと無いからのような気もしなくもないけど。このエントリは素敵すぎです。いやらしさをよく表現しています。使おうが、そのスパゲティから逃れることはできません。この問題から逃れることができないのか、考えて見ましょう。継承したクラスにイベントハンドラを追加していくスタイルは、一見すると、わかりやすくて簡単です。継承したクラスはスパゲティになります。採用したフレームワークにしたがって書けば、関心ごとがそこそこ分離され、わりと綺麗に書けます。プログラミングの場合、フレームワークに従っても、複数の関心ごとを分離してはくれません。開発者は自衛する必要があります。スタンドアロンアプリでも本質的に同じ問題を抱えています。すれば、このいやらしさから逃れられるか考えて見ましょう。アプリの場合のアイディアを書きます。絡みそうなもの)を前提にしています。みたいにモードを作ってもいいです。アプリでは、特定の作業をしているときに、特定の入力を排除するようなことがあります。保存中に全ての入力を排除するとかですね。部品が、どのイベント(キーとかマウスとか)を受け付けるか、わかりやすく定義できるような抽象化が望ましいです。部品は構造化しておくと、粒度に応じた管理が出来るようになります。状態遷移図を書いて整理して、状態遷移を実現するフレームワークを書いて抽象化してもいいでしょう。サーバと通信があるなら、それも考慮した状態管理を行いましょう。キーを押したりするとちょっと変な動作をします。状態管理だけを行おうイベントハンドラにアプリの処理を書かないようにしようということです。状態管理に徹させることです。状態に応じて、別のクラスか関数に書いたアプリの処理を呼び出しましょう。変更処理とは、たとえば、チャットの場合、ユーザーの発言を受信したら画面を書き換えたりするようなことです。するような処理は別です。いう処理は、状態管理で考えてください。アプリの処理とは、チャットなら、クライアントで発言ログやログインユーザを管理したりするような処理です。変更処理の分離を検討した方がいいです。当てはまらない場合は行う必要はありません。それはないかもしれません。サーバとは異なるモデルかもしれませんが、クライアントにモデルが必要になら、ちゃんと定義しましょう。クライアントにもモデルを定義しています。アプリ処理、画面変更、サーバとの通信の順序を決めようそのままです。機能ごとに上記の順序が変わるとわかりにくいので、決めた方がいいです。こんな感じかなと思います。ついては経験不足です。行位しかなく、小さなものしか作ったことがありません。akiyan.comイベントドリブンでステートフルなGUIプログラミングには、いわゆるWebサーバーアプリーケーションでの抽象化経験は全然役に立ってる気がしません。余計に感じたりします。無駄になるということは無いと思います。要は関心ごとの分離ですから。アプリはフレームワークを「作る」ことになるという違いはあります。アプリを作ったら自滅しますね。いう意味では、上記の余計に感じるという表現は非常に示唆に富んだものだと思います。