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

Java

なんか、いろいろあって、
月曜朝から火曜夜まで働き詰めになることになりました。
死なないようにがんばります。

ということで、前回の続き。

データの群れからかな。
これは、クラスにするか、そのままかの判断が難しい。
各項目が非常に強い関連を持っている場合は、別として。
大体の判断なら、それらを操作するメソッドがあれば、それごとクラスにしちゃうのがいいんじゃないかと。
メソッドが鍵ですね。

一次属性は、こんなんあるかなーって感じですね。
昔のコードみたらあるかもしれないけど、
最近はこんなの見たことないわ。　ちょっとは成長したってことかな？

相続拒否も同じ。こんなのしたためしが無いし、
ここには、複雑でなければそのままにしとけとかいてありますが、
絶対に設計を見直すべきです。
これは、声を大にして言いたい。
基本的に、原則(ここでいうLSP)違反は「臭い」に他なりません。
必ず解決策はあるはずなので、それを探しましょう。

不適切な関係は見てて、あー最近やらなくなった。って思った。
継承は、拡張として使うことが殆ど無くなったので、その成果が出てるのかもしれません。
継承は、ポリモーフィズムと抽象化(疎結合の維持)のために使うもんですね。

怠け者クラスは、作ったことあるかなーって言うくらい。
特にコメントはなし。

次のページのAbstractを作るのは、無駄な空実装をしないように？
かな？　コードの重複よりマシってことなのかね。

次。責任。
属性、操作の横恋慕。
ユーティリティー関連はみんなこれ？
まぁ、多少はしょーが無いんじゃないかと。それが最良の実装ならね。
よーわからんってのがホンネ。

不適切な関係も、よーわからん。
なんか、Amazonのコメントが正しいと実感してきた(笑

メッセージの連鎖。
ここまですごいのはしないね。
クラスがフィールドのgetterを持っていて、
そのフィールド(クラス)が他の責任を持っていて、
特定の機能のみをそのクラスを介して行いたいときは、
委譲メソッドを作成するように。ってことですね。
Tell, Don't Ask　は初めて聞きました（汗

仲介人は、必要な時しか作らないこと。ってことですね。
そのままですが。
先を見越した(実際は見越してない)実装を行うと、こういうことがよく起きる気がします。
Agileにやってれば、これはまず無いでしょう。

Proxyは殆ど使ったことが無いです。
デコレータはハマるとすごい力を発揮する感じですね。
下手に使うと、複雑で使いにくくなっちゃいます。

仲介人はArrayListを使うなってことみたいですが、
ArrayListを使うのがベストでしょう。
そもそもArrayListなどのjava.utilに属するクラス群はStringと同列程度の基本データとして扱う傾向にあるので(私のなかで)
とくにこれらに依存して、処理することは間違いじゃないと思いますね。
ただし、
ArrayList array = new ArrayList();
は素人。
List array = new ArrayList();
にしましょう。　変数名が良くないけど。そこは気にせずに。

カートは
Purchaseにcostメソッドを作成すればOKでしょう。
そんで、itemとshippingは隠せるようなら隠しましょう。

Swingはあれなのかな。
JTreeはコンポーネントとしての責任をおっていて、
Treeとしての責任はTreeModelに托している。
TreeModelは他でも使用する可能性があるので、別パッケージに置いた。これはパッケージ全再利用の原則に沿っているので、OKだと思いますね。
それが依存関係を切り離してるって言うやつかな。

馴れ合いの変更。
変更の発散はよくやっちゃいます。
よくよく考えないと、これを守るのは難しい。
まぁ、本当に複雑になれば。ですが。

CsvWriterは、よくわかんなかったんだけど、
どうやら、System.outを使ってるからみたいね。
まぁ、そりゃそうだって感じですね。

これは、出力クラスを別に用意するべきってことですね。
ただ、こういうのは、よくみかけるんだけど、
どこまで抽象化すればいいのか分からない。
とりあえず、writeメソッドを持ったインターフェイスでも用意してやればいいのか？　うーん　微妙なところ。いつもなやむ。