<< 前 ホーム 次 >>

bakaid: 20101221

さすがに、今どき、インスタンス変数はprivateにする
のは常識なんだけど。でも、publicなsetterがあったら
台なしなんだよね。

publicなsetterっつっても、状態遷移を引き起こすような
ヤツね。これは特に危ない。

1つのオブジェクトを状態機械と見なしたら、それに外部
から作用できるのはイベント入力なんだよね。状態の
遷移先っていうのは、そのオブジェクトが決めるもの。

状態遷移を引き起こすようなpublicなsetterがあるって
いうことは、状態遷移がオブジェクトの外部で決まってる
ってことで、何のためにオブジェクト使ってるの?って
話になる。

だから、状態遷移を引き起こすようなpublicなsetterは
除去するのがリファクタリング。

--

publicなsetterがあっても、そのクラスのメソッドでは
インスタンス変数に直接アクセスしてるってことは、
ごく普通にある。

で、上で書いたみたいなsetterを除去するときは、
リファクタリングでいうところの自己カプセル化
フィールドが役立つ。

特に、今どきのコンパイル型言語ならばツールの支援が
受けられて、どこでsetterが呼ばれているかが一目瞭然に
なる。

--

ボタンが押されたら、(インスタンス変数として表現されて
いる)フラグを立てて、それに続く一連の処理の途中で
そのフラグを見て処理を変えて、その直後にフラグを
落とすっていうのはダメパターンなのね。

だったら、そのフラグを引数として渡したほうがわかり
やすいし、もしかしたら、本来違う流れなのをムリヤリ
ひとつにまとめてるのかもしれないし、より構造的な設計
(Stateパターンとか)を必要としているサインなのかも
しれない。

--

製品っていうのは共有地なんだよね。

メーカーにとっても、顧客にとっても。

元請けにとっても、下請けにとっても。

本家Permlink

<< 前 ホーム 次 >>


Copyright © 1905 tko at jitu.org

バカが征く on Rails