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

なんか連載のようになってしまったんだけど、
とりあえず、今日もこの話でつっ走ってみます。

クラスのインターフェイス不一致から。
今は、一人での開発が多いので、そんなことは起こらないんだけど、
誰かのライブラリを使う場合とかはよく起きるね。
そういうときは、Adapter。これで決まり。って思ってるけど、
あんまりそういう機会に巡りあったことがありません。
とりあえず、LoggerだったらLog4J使えばいいしね。
Loggerを変えることはまずないでしょう。

これは、一致してないのをなんとかするってことなので、
とりあえず、この通りでしょうね。
まぁ、開発するときに作ったものをまず確認することで未然に防ぐのがベストですね。
XPだと、ペアプロと定期的なパートナー交換でこの要因を未然に防いでいるので、やっぱりペアプロというか、コードの共有ってのは大事ですね。


次の問題は、プロパティからデータをとって。変換前チェック、変換後チェックまでがメソッドになるね。
int getPropertyValue(Property prop, String key);

その次も考えは一緒。
String replace(String baseValue, String findValue, String replaceValue);

次のオブザーバデータの複製ってのは、
Observerパターンの有用性について解いているのかな？
とりあえず、疎結合になるってことでいいのかと。
ちょっと意味が汲めなかったので、間違ってるかも。

で、その後は似てるので、ちょっと飛ばして
条件分岐ロジック。
ヌルチェックは、DBのConnectionをwrappingしてやると、
close()がきれいに書けて良い。
DBからデータが取れないときにNullObjectを返すってやり方は、相当特殊な環境じゃない限り、うまくいかない。
こと、実際の開発じゃ、NullObujectでうまくいくのは、下層部分とかFramwWork内部に限られるんじゃないかな？

複雑なBoolean式は、ドモルガンを適用するより、
メソッド化するとかした方がいい気がします。
ただ、条件がその処理とかみ合ってない場合は、
修正の必要があると思います。
例えば、
フラグが1から5までの範囲で変動する場合に、
2と4の場合を取りたいときに、
if (1 != flag && 3 != flag && 5 != flag)
なんて書いてるなら、
if (2 == flag || 4 == flag)
と書くべきです。　当り前だけど。
そんでもって、これの応用だけど、
2と4以外の処理を書くときに、
if (2 != flag && 4 != flag)
と書くのも良いと思うけど、
if (2 == flag || 4 == flag) {
//空行
}else {
}
と書いた方が良い場合もあります。
たとえば、その2か4かの判断が多いときは特に。
間違いが起きないようにコピペの方が安全ってね。

まぁそんなことするくらいなら、メソッドにしろって話ですね。

フラグの判定が多用される場合は、
inメソッドを作ると良いかも知れませんね。
boolean in(int flag, int[] values);
みたいな。　結構重宝します。


疑似継承に関しては、switchが出てきたら速攻対応すべきです。
ハッキリ言ってswitchを「なんの疑いもなく」使うようなプログラマはダメダメでしょう。switch使う位なら、別の方法を考えましょう。　本当に必要な場合があるのも事実ですが。

今日の最後。
基本データ型への執着です。
これは、たまにやっちゃいますね。
まぁいいだろーって思うとダメですね。
ちょっとでも匂いがしたら、検討してみるのがベストですね。

ついでに、データクラスはHibernate使う上で必要なので、普通に使ってます。　こういうのは例外でしょうが。
他のデータをまとめれば、そこに属するメソッドが見付かるハズなので、それがない場合は、まとめるのを一度考え直し他方が良いかもしれませんね。