リファクタリングワークブック その2

今日は、巨大なクラスからクラスインターフェイスの不一致あたりまで読み進めました。

巨大なクラスはSimpleSVNClientで苦しめられたJTableクラス。データは別クラスが管理しているのにも関わらず、このメソッド量。多すぎます。
デザイン系を別クラスにした方が良いような気がしました。

多すぎる引数は、RectangleやRangeで置き換えられるものばかり。
ただ、メッセージボックス出力メソッドとかは、呼び出しが面倒になるので、あまり引数をオブジェクトにするのはどうかと感じましたね。

次は、名前。　これは大事です。
ハンガリアン記法は古いと。C++使ってたころは使ってたけど、最近は全然使ってませんね。　最近はローカル、フィールド関係なく命名しちゃってます。　これもIDE依存だとバッチリ分かるので、名前を考えなくても問題ないですね。
一時期、フィールドは_を付けるのをやってましたが、
あれはあれで利点はあります。
例えば、フィールドの一覧が見たいときは、_を打った後Ctrl+Space。これで一覧が見れるし、
引数とフィールドの名前がかぶることがないので、thisを使うことが少なくなります。
このへんは、コーディング規約に従いましょう。

情報を伝達しない名前は当然ですね。
swapの時の一時変数は大体tempにしちゃいますが。
本当は何がいいんだろ？

一貫性のない名前はたまにやります。
一番間違うのがstart-stop begin-endの組合せ。
start-endにしてしまいがち。

あとは、clear()やerase()は全て削除のイメージがありますね。

実行されないコードは書かないので、問題なし。
必要なことしか書きません。

疑わしき一般化もベタで作っていくなかで、必要になったらリファクタリングするようにしているので、殆どやらないですね。
事前に分かってる場合は、やりますけど。事前に分かってる程度だとやりすぎるってこともあります。

マジックナンバーはあんまり意識してませんが、一応外だしするようにしてます。
重複したコードは、疑わしき一般化とのトレードオフって感じですね。　やりすぎもダメだし、やらなすぎもダメってことですね。
難しい。

今日やったところは、問題が抽象的でちょっと意味がわかりにくかったですね。
問題が抽象的なのもあるけど、翻訳がちょっと。なところもありで。