平鍋です．
楽しい議論で盛り上がっていますね．
> > XPでは今分かっているものを、シンプルに実現することに注力する訳ですけど、
> >
> > シンプル ≒ 自然な役割分担
> >
> > と考えてよいのだとうと思います。
> 個人的な感想から言うと、「自然な役割分担」と思う状態は個人によって差が
> あって、誰もが曖昧さなく納得するのは難しいような気がします。「シンプル」
> というのは、「重複がなく、これ以上リファクタリングすべきコードが残ってい
> ない」と言い換えれば、達成したかどうかが誰でも同じ基準で納得できるような
> 気がします。
なるほど．「シンプル」がより「現実的な」基準ということですね．賛成です．
また，どちらの場合でも，「名前」に注目するとその分割，分担が良いかどうか，
が見えるというケースが多いと思っています．
ちょっと平鍋なりにロジックを作ってみます（未完）．
まず，「よい設計」として，次の「ビジネス的価値」基準を出発点とします．
・プログラムの開発・保守のトータルコストが低いこと
・プログラムを早期に出荷すること
・プログラムがビジネス変化に対応すること
このためには，
（１）仕様変更のコスト・タイムが小さい ⇒ extendibility(architecture 連続性)が高い設計
（２）欠陥除去のコスト・タイムが小さい ⇒ testability が高い設計
という２つクライテリアが重要です．（正の変更と負の変更のコスト）
そして，それを支える
（３）プログラムの理解コスト・タイムが小さい ⇒ human-readability(=understandability) が
高い設計
が最も重要です．
--------------------------
（１）は
【Extendibility Principle】(by Meyer)
・Small changes of specification should yeild small change of architecture.
仕様をX軸，アーキテクチャをY軸に取ったとき，その関数が連続関数であること，
つまり少々の仕様変更は少々のアーキテクチャ変更になること．
【Software Design Principle】(by Meyer)
・Build it for change.
（２）はXPの規則でもある【Software Should be Tested】これがなければ
ソフトウェアを「正しい」と言うことができない．
--------------------------
さて，「責務分担」ですが，まず，（３）の
understandability（理解しやすい）を重要としましょう．
これは「説明しやすい」とも捉えられます．そうすると，
（Ａ）現実の世界と直接対応【Direct Mapping Principle】(by Meyer)
（Ｂ）シンプルである（直接対応でないが，簡単である）(by Beck)
という２つの分担方針があるか，と思います．どちらの場合にも当てはまる，
責務分担の原則は，次に原則に照らして評価できます．
（Ａ）（Ｂ）に共通する原則
--------------------------
【A Good Abstraction Has A Good Name】
・よい抽象化は，よい名前を持つ．（by 平鍋)
--------------------------
ここまでで，もっとも重要な（３）のunderstandabilityという性質については，
（Ａ）（Ｂ）の２つの方針があり，どちらでも「良い名前が付けられる」という
ことが一つの条件になりうる可能性を示しました．（実際は，Ａ’として
メタファを使うことができ，これもunderstandabilityを上げます．そして
それでも，現実世界⇒認識世界と置きかえることで，MeyerのDirect Mapping
Principleは機能します）
次に，（Ａ）と（Ｂ）は対立するクライテリアとなることがあります．
これは，（１），（２）の正負の変更に対する容易さとコストの
トレードオフになります．．．．．
と，ここまで，書いて，うまくまとまりませんでした(^^;)．．．．ただ，
「テスト可能性」と「変更に対する追随性」でもって，うまくオブジェクト指向
的な「よい設計」を再定義できる気がしています．
old:
よい Separation of Concerns ＝ 自然な責務分割 ＋ 強い凝集度 ＋ 弱いカプリング
new:
よい Separation of Concerns ＝ 変更を伝播させない分割 + テスト可能な分割
以上