塚本です。
>>>>> "YT" == Yoshihiro Tsukamoto <y-tukamoto@....jp> writes:
YT> (2)の別解として、「事業所」「部」「課」は class 「組織」の role にする、
YT> というのは「無し」ですか? 個人的には、それも「有り」かと思いました。
「role にする」だけでは何のことかさっぱり伝わりませんね。class 組織 に
role 「組織の種類」として関連する別のクラスを仮定して、「事業所」「部」
「課」の類はそのクラスのオブジェクトが持つ属性の値にする、という解です。
また、下記の
YT> しかし、将来に備えないという境地にはなかなか到達できません。モデルでは、
YT> アナリシスパターン等を手本にして将来に備えておく方が良い気がしています。
YT> 考えようによっては "simplest" も実装詳細に関わる一要因であり、モデルが
YT> そこに特化するとシステムそのものが「短命」に陥る気がするのです。
YT> モデルでスパイラルを回すことに反対しているわけではないのですよ。ただし、
YT> 実装コードの refactoring ほど頻繁には更新できないでしょう。また、実装
YT> レベルならばテスト仕様を維持しつつ refactoring 出来ても、モデルの変更
YT> はテスト仕様にかなりのインパクトを及ぼすはずです。
YT> 私としては、
YT> (最初は) 見切れない将来に対して、モデルは短命にならないよう備える。
YT> その一方、テストケースや実装コードは simplest にする。
YT> (途中は) 変化を抱擁することを目指して、refactoring を繰り返す。
YT> (最後は) 見切れた領域に対する整備された下地の利用を主にして、
YT> コード記述はほとんど必要無いようにする。
YT> ような工程を目論んでいます。最後の状況は XP から外れるかもしれませんが、
YT> やはりそこをゴールにしたいのです。
では用語が思い付かなかったので「モデル」という曖昧な言い方をしてしまい
ましたが、「アーキテクチャの根幹に関わるほどリスクが高いモデル要素」の
つもりでした。
ごめんなさい、お詫びして訂正します。
--
Yoshihiro Tsukamoto