teratail header banner
teratail header banner
質問するログイン新規登録

回答編集履歴

2

追記

2018/02/27 12:23

投稿

KSwordOfHaste
KSwordOfHaste

スコア18404

answer CHANGED
@@ -5,4 +5,15 @@
5
5
  ところがGUIというのは「依存関係が複雑に錯綜しているのが普通」です。
6
6
  例えば「プログラム側で何かの計算をしてテキストフィールドにその結果を表示する」といった場合、ユーザーがテキストフィールドにアクセスできる以上は「プログラムが計算を開始する時点でテキストフィールドを操作できないようにロックする」なんてことが必要になるでしょう。では「結果を複数のコントロールへ反映させる」というような場合はどうなるでしょうか?それらのコントロールのロックを順番に全部取得してから計算を始めればよいでしょうか?
7
7
 
8
- 「複数のリソースをロックする」なんて設計は「ロック順序を少しでも設計し間違えると簡単にデッドロックを起こす」ためたいていの場合忌避されると思います。それをあえてやろうとしてもそんな複雑な設計を「GUIプログラミングをしようとしているアプリケーションプログラマーに要求する」のはあまり現実的とは言えないと自分は思います。
8
+ 「複数のリソースをロックする」なんて設計は「ロック順序を少しでも設計し間違えると簡単にデッドロックを起こす」ためたいていの場合忌避されると思います。それをあえてやろうとしてもそんな複雑な設計を「GUIプログラミングをしようとしているアプリケーションプログラマーに要求する」のはあまり現実的とは言えないと自分は思います。
9
+
10
+ ---
11
+ 追記:思いつきに近い状態でコメントしたためいささか支離滅裂な内容になってしまったと思います。
12
+
13
+ 例えば「依存関係が複雑に錯綜」は自動レイアウト機能をイメージしました。親部品と子供部品の間でレイアウト制約に従ってややこしい手順でレイアウトが決まる処理過程を「適切に排他制御する設計はやりきれないだろうな」といったことをイメージした内容だったのですが、それはGUIシステム一般についていえるような話ではなく特定のシステム固有の機能についての話であり、質問者さんが問いかけていることの焦点からははずれた内容だったと思います。
14
+
15
+ さらに上記をイメージしてロックの困難さを書こうとしたものの、前述のレイアウト動作の複雑さを説明するのがわかりにくそうだったためかけ離れた例(複数のコントロールへの状態反映の例)をかいちゃいました。
16
+
17
+ 整理できてないままおかしな内容をコメントしてしまい失礼しました。
18
+
19
+ どちらかといえば「イベントが発生する順番にハンドリングする必要があり、そうした処理のシリアライズが必要だからこそ単一スレッドで設計するのが素直」とでも主張した方がまだましだったと思います。

1

表現変更

2018/02/27 12:23

投稿

KSwordOfHaste
KSwordOfHaste

スコア18404

answer CHANGED
@@ -5,4 +5,4 @@
5
5
  ところがGUIというのは「依存関係が複雑に錯綜しているのが普通」です。
6
6
  例えば「プログラム側で何かの計算をしてテキストフィールドにその結果を表示する」といった場合、ユーザーがテキストフィールドにアクセスできる以上は「プログラムが計算を開始する時点でテキストフィールドを操作できないようにロックする」なんてことが必要になるでしょう。では「結果を複数のコントロールへ反映させる」というような場合はどうなるでしょうか?それらのコントロールのロックを順番に全部取得してから計算を始めればよいでしょうか?
7
7
 
8
- 「複数のリソースをロックする」なんて設計は「ロック順序を少しでも設計し間違えると簡単にデッドロックを起こす」ためたいていの場合忌避されると思います。それをあえてやろうとしてもそんな複雑な設計を「GUIプログラミングをしようとしているアプリケーションプログラマーに要求する」のはナンセンスに近だと自分は思います。
8
+ 「複数のリソースをロックする」なんて設計は「ロック順序を少しでも設計し間違えると簡単にデッドロックを起こす」ためたいていの場合忌避されると思います。それをあえてやろうとしてもそんな複雑な設計を「GUIプログラミングをしようとしているアプリケーションプログラマーに要求する」のはあまり現実的とは言えないと自分は思います。