赤坂です。
平鍋さんのロジックをもう一度整理してみます。
Kenji HIRANABE <hiranabe@....jp> san wrote:
> （１）仕様変更のコスト・タイムが小さい ⇒ extendibility(architecture 連続性)が高い設計
> （２）欠陥除去のコスト・タイムが小さい ⇒ testability が高い設計
>
> という２つクライテリアが重要です．（正の変更と負の変更のコスト）
>
> そして，それを支える
>
> （３）プログラムの理解コスト・タイムが小さい ⇒ human-readability(=understandability) が
> 高い設計
>
> が最も重要です．
..snip..
責務分担について、まず(3)から始めると、
> （Ａ）現実の世界と直接対応【Direct Mapping Principle】(by Meyer)
> （Ｂ）シンプルである（直接対応でないが，簡単である）(by Beck)
以上の2通りの方針がある。
> 次に，（Ａ）と（Ｂ）は対立するクライテリアとなることがあります．
> これは，（１），（２）の正負の変更に対する容易さとコストの
> トレードオフになります．．．．．
これは、ちょっと理解できませんでした？
> と，ここまで，書いて，うまくまとまりませんでした(^^;)．．．．ただ，
> 「テスト可能性」と「変更に対する追随性」でもって，うまくオブジェクト指向
> 的な「よい設計」を再定義できる気がしています．
(3)についての理解性の高い責務分担が出来たとして、
このあと、(1)、(2)について検討していきます。
(1) 変更容易性については、
ドメインエキスパートの視点で「揺さぶり」をかけて、予想される変更に
対応可能で、かつ自然な構造を見つけていきます。(※1)
# これは、YAGNIを善しとするXPでは重要視されないかもしれませんが。
(2) テスト容易性、テスト可能性については、あまり具体的でないですが、
凝集度を高く、弱い結合度にすることで、単体テストが容易になるはずです。
> old:
> よい Separation of Concerns ＝ 自然な責務分割 ＋ 強い凝集度 ＋ 弱いカプリング
>
> new:
> よい Separation of Concerns ＝ 変更を伝播させない分割 + テスト可能な分割
「変更を伝播させない分割」については、
クラスレベルではなくサブシステムレベルですが、
シュレイアーメラー法、あるいは eUML のドメイン分割という方法が最も効果的
な分割ではないかと思います（説明は省略します）。
クラスレベルでこれを実現するのは、今の私のレベルでは難しいです。
現状では、パッケージ内部については妥協（変更の伝播を容認）し、外部のパッ
ケージに変更の伝播がなければOKとしています。
# もちろん、単体テストを考えると、パッケージ内部のクラス同士も関係は疎な
# 方が良いのですが、うまく実現できていないので、当然整理もできません。
これはサブシステムレベルで高い凝集度と疎な結合度を実現した場合と考えられ
ますので、結局は(1)、(2)を検討すると、old と new は同じものに行き着くの
ではないかというのが、私の考えですが、ちょっと話が飛躍しすぎの感がありま
すね(^^;;。
以上、整理したつもりですが、肝心の
「変更を伝播させない分割」や「テスト可能な分割」の具体例が思い当たらない
ので、話がまとまらないみたいです。
誰か、これらの具体例を紹介していただけませんでしょうか？
そうしたら、もう少し検討できるかもしれません。
ではでは。
# もっといろんな人の意見が聞いてみたいなぁ。
# 管理人様、ごめんなさい m(_._m。
P.S.
(※1)「揺さぶり」は日経ITProの連載記事でエクサの児玉さんがおっしゃってい
た言葉で、典型的なクラス構造を出した時点で満足せず、仕様変更に対応できる
ように 現状の仕様「＋α」の視点から柔軟性の高いクラス構造へ改善しようと
いうことです。
私の場合、揺さぶりすぎて(不要な揺さぶりのせいで?)クラス構造が「複雑」に
なってしまうことが多々あります。
同僚からは「やりすぎ」と言われてしまいます。
# XPでは揺さぶらないんですよね。ビッグリファクタリングの匂いが嗅ぎ分け
# ることが出来れば、きっと必要なときは揺さぶることになると思いますが。
# だって簡単にリファクタリングできる範囲は限られてますしね。
--
赤坂 英彦 (Hidehiko AKASAKA)
akasaka.h@....com