Java読書会「オブジェクト指向のこころ」第3回実施

デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series)

3月度のJava読書会を本日開催しました。参加人数も17人とまずまずの人数です。
http://www.javareading.com/bof/

今回のパートでは、随分とAlexander氏の書籍を引用していました。そのアプローチが有効なのかどうかは次回読書会のパートになります。次回が楽しみです。

GoFのパターンは今までもいろいろなところで見聞きし読んできたのですが、Bridgeパターンでは本質の理解が違っていたなと認識を新たにすることもあり、これは読書会ならではの効果です。

今日の読書会でのメモから

読書会中に、書籍内容・議論内容から発想・連想したことの箇条書き

• 納期プレッシャーから保守性は先送りし目先の問題解決をすることについて

ライフサイクルコスト（保守コスト）までの責任を持つのは誰か？ 受託開発ではSI側（のマネージャ）にとってはプロジェクト採算に責務を持つのでライフサイクルコストは優先度が低くなるので、やはり発注側の責務。しかし現状のシステム丸投げ体質では発注側で責務を負うのは無理がある。保守性以外の品質についても同様かもしれない。

プログラマの視点に立ったときに、保守性を高めるためにデザインパターンを活用して設計をする場合、往々にしてクラス数／メソッド数が増える（ステップ数とは相関しない）。クラスを増やすのに抵抗がある場合（例:クラス試験手順書・成績書を作成しなくてはならない）、納期プレッシャーの元ではそれを避けようとする力が働くことになるかもしれない。

保守性、品質について責務を持って開発の中に入って影響力を行使するような体制が必要です。

• Bridgeパターンはオブジェクト指向設計を学ぶ好例

抽象的側面(abstraction)と実装(implementation)に分離するという点ですが、これは抽象クラスと具象クラスのことではないと解説があり、認識を新たにしました。

・流動的要素を探し出してカプセル化する
・クラス継承よりもオブジェクトの集約を多用する

という原則に従ってBridgeパターンでは、抽象的側面と実装をお互いの存在を気にかけることなく別々に変更できるようにしています。なるほど。

• 複数の設計案を模索するという習慣

是非身に付けたいです。

• なぜGoFは"Abstract Factory"と呼んだのか？

ファクトリが抽象クラスになっているからではありません。
構築しようとしているもの自体が抽象化によって定義されているからです。

• 生成方法を考える前に、システム中に保持する必要のあるものを考察すること

はい。

• クラス・メソッドを増やすには

クラス・メソッドが増えるとテスト対象が増えるから、という誤った判断をなくすために、分岐カバレッジを取るようにするとよいのかな。フラグを増やして既存メソッド内に条件分岐を増やせば、そのメソッドのテストが指数的に増えるので、結果としてクラスを増やす方が簡単となる（設計がシンプルになる分テストもシンプル）と考えます。なお、ケーススタディしていないので・・・・

• 派生による再利用は時とともに保守が難しくなる

その通りですね。