トップページ > プログラム > 2014年11月12日 > 5GyhUZuz

書き込み順位&時間帯一覧

27 位/182 ID中時間01234567891011121314151617181920212223Total
書き込み数0000000000000000000020002



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
クラス名・変数名に迷ったら書き込むスレ。Part24
クロージャって何がいいの? [転載禁止]©2ch.net

書き込みレス一覧

クラス名・変数名に迷ったら書き込むスレ。Part24
950 :デフォルトの名無しさん[sage]:2014/11/12(水) 20:25:33.67 ID:5GyhUZuz
>>942
もし省略可能(optional)な入力フィールド上で特定の条件(たとえばチェックボックスがオンの時)だけ
編集を許可したいという、ありふれたケースであれば:
・(1) を isEditable として (2) を isActive という論理型の属性にするか、
 あるいは Active(活性中)/Inactive(非活性) という列挙型にする
・またはより一般的(総称的)に (2) を isEnable という論理型の属性、または
 Enable(有効)/Disable(無効) という列挙型でもいい

または特定のユーザが持つ権限に応じて編集可能性が決定するケースであれば:
・(1) を isEditable として (2) をアクセス制御を表す isAccessable という論理型の属性、または
 Allow(許可)/Deny(禁止) という列挙型にする
・またはより一般的(総称的)に (2) を isPermitted という論理型の属性、または
 Permit(許可)/Prohibit(禁止) という列挙型でもいい(>>943)

これらのユーザの対応によって回復可能なエラーを例外で実装すること(>>944)が正当されるケースは、
まず有り得ないと思う
GUIアプリのコード設計で例外を投げて対処するのが明らかに正当化されるケースは、
処理を続行できない致命的なエラーを検出したケースくらいだろう


これらはGUI部品オブジェクトのインスタンス状態が実行中に(=動的に)変化する場合だけど、
設計時に(=静的に)編集可能性が決定する局面もある
たとえばテキストや画像のラベルは「そもそも」編集不可だし、
テキスト入力フィールドやリストボックスは「そもそも」編集可能という属性値を持つ
これをコードで実装するケースであれば:
・(1) をクラス属性として実装して (2) をインスタンス属性として実装し、命名はどちらも isEditable とする
クロージャって何がいいの? [転載禁止]©2ch.net
130 :デフォルトの名無しさん[sage]:2014/11/12(水) 20:38:24.71 ID:5GyhUZuz
>>128
代案も出さずに批判だけするなら、幼稚園児にだってできるよ


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。