回答編集履歴
2
追記
test
CHANGED
|
@@ -13,3 +13,25 @@
|
|
|
13
13
|
|
|
14
14
|
|
|
15
15
|
「複数のリソースをロックする」なんて設計は「ロック順序を少しでも設計し間違えると簡単にデッドロックを起こす」ためたいていの場合忌避されると思います。それをあえてやろうとしてもそんな複雑な設計を「ＧＵＩプログラミングをしようとしているアプリケーションプログラマーに要求する」のはあまり現実的とは言えないと自分は思います。
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
追記：思いつきに近い状態でコメントしたためいささか支離滅裂な内容になってしまったと思います。
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
例えば「依存関係が複雑に錯綜」は自動レイアウト機能をイメージしました。親部品と子供部品の間でレイアウト制約に従ってややこしい手順でレイアウトが決まる処理過程を「適切に排他制御する設計はやりきれないだろうな」といったことをイメージした内容だったのですが、それはGUIシステム一般についていえるような話ではなく特定のシステム固有の機能についての話であり、質問者さんが問いかけていることの焦点からははずれた内容だったと思います。
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
さらに上記をイメージしてロックの困難さを書こうとしたものの、前述のレイアウト動作の複雑さを説明するのがわかりにくそうだったためかけ離れた例（複数のコントロールへの状態反映の例）をかいちゃいました。
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
整理できてないままおかしな内容をコメントしてしまい失礼しました。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
どちらかといえば「イベントが発生する順番にハンドリングする必要があり、そうした処理のシリアライズが必要だからこそ単一スレッドで設計するのが素直」とでも主張した方がまだましだったと思います。
|
1
表現変更
test
CHANGED
|
@@ -12,4 +12,4 @@
|
|
|
12
12
|
|
|
13
13
|
|
|
14
14
|
|
|
15
|
-
「複数のリソースをロックする」なんて設計は「ロック順序を少しでも設計し間違えると簡単にデッドロックを起こす」ためたいていの場合忌避されると思います。それをあえてやろうとしてもそんな複雑な設計を「ＧＵＩプログラミングをしようとしているアプリケーションプログラマーに要求する」のは
|
|
15
|
+
「複数のリソースをロックする」なんて設計は「ロック順序を少しでも設計し間違えると簡単にデッドロックを起こす」ためたいていの場合忌避されると思います。それをあえてやろうとしてもそんな複雑な設計を「ＧＵＩプログラミングをしようとしているアプリケーションプログラマーに要求する」のはあまり現実的とは言えないと自分は思います。
|