「メモ/モデリング」の編集履歴（バックアップ）一覧に戻る

メモ/モデリング - (2008/02/12 (火) 03:22:34) のソース

*モデリング原則
>モデルは正しいか誤っているかではなく、使いやすいか使いにくいかである。

[[アナリシスパターン>http://www.amazon.co.jp/dp/4894716933/]], p.2

>概念モデルは実装（クラス）ではなく、インタフェース（型）につながっている。

[[アナリシスパターン>http://www.amazon.co.jp/dp/4894716933/]], p.4

>最も頻繁に起こるモデルの変更が、最少の型の変更ですむようにモデルを設計せよ。

[[アナリシスパターン>http://www.amazon.co.jp/dp/4894716933/]], p.22

>モデルを操作レベルと知識レベルに明示的に分割せよ。

[[アナリシスパターン>http://www.amazon.co.jp/dp/4894716933/]], p.26

>複数の等価な特性の集合が得られたときは、そのドメインエキスパートが最も満足のいくものを選択せよ。もし、ドメインエキスパートが双方とも大変価値があると考えるならば、両方を表示し、一方に導出とマークせよ。

[[アナリシスパターン>http://www.amazon.co.jp/dp/4894716933/]], p.185

>特性を導出として記すことはインタフェースの制約となる。その下にあるデータ構造には影響を及ぼさない。

[[アナリシスパターン>http://www.amazon.co.jp/dp/4894716933/]], p.185

>ある処理をある型の特性とするとき、処理には抽象的インタフェースを与え、サブクラス化によって実装を容易に変更できるようにすべきである。100％ハードコードによる実装は1つのサブクラスであり、また、パラメタ駆動によるさまざまな方法も別のサブクラスである。

[[アナリシスパターン>http://www.amazon.co.jp/dp/4894716933/]], p.189

>複数の属性が、いくつかの型で使われる振る舞いと相互に影響し合っているとき、それらの属性は新たな基本型としてまとめられるべきである。

[[アナリシスパターン>http://www.amazon.co.jp/dp/4894716933/]], p.193

*文献
-[[The Tao of Modeling Spaces>http://www.jot.fm/issues/issue_2006_11/article4/]]