• 履歴一覧
• 現在との差分 を表示
• ソース を表示
• 履歴 を表示
• 設計パターン/ファーストクラスコレクション へ行く。
  • 1 (2014-05-24 (土) 22:41:43)
  • 2 (2014-05-25 (日) 07:46:44)

• 追加された行はこの色です。
• 削除された行はこの色です。

* キーワード [#i5588508]
- 集約
- コレクション
-- 配列
-- リスト

* 何か [#ec18191a]

 中間管理職

配列やリスト(コレクション)によって集約するクラスをひとつのクラスとして独立させます。たとえば、伝票(Slip)と明細(Detail)を考える場合Slip、Details、Detailの関係を設計します。

#ref(first-collection.png,center)

* なぜか [#pf3aa25b]

コレクションにてあるオブジェクトを集約する場合、そのコレクション全体を取り扱う処理が考えられます。たとえば、明細の合計金額を計算するなどがそれにあたります。このようなコレクションに対する処理は複雑で(集約する側において)冗長になりがちです。また、コレクションに対する処理は形式的で処理内容の意図が読み取りにくいものです。

- 複雑
- 冗長
- 見通しが悪い

コレクションに対する処理を集約する側に寄せると、集約する側をこれら問題のたまり場にしてしまいます。そこで''コレクションに対する処理をするためだけのクラス''を独立させ、これら問題にあたらせます。

* どのように [#g9b6c9fb]

配列やリストによって集約する属性をひとつのクラスとして独立させます。

たとえば、次のように考えた伝票と明細の関係について。
 Slip {
 
   List<Detail> details;
 
   // return sum of details
   sum() {
     sum = 0;
     for (detail: details) {
       sum += detail.amount;
     }
     return sum;
   }
 
 }

Listとして集約しているDetailをDetailsとして独立させます。
 Slip {
 
   Details details;
 
   // return sum of details
   sum() {
     return details.sum();
   }
 
 }

 Details {
 
   List<Detail> collection;
 
   sum() {
     sum = 0;
     for (detail: details) {
       sum += detail.amount;
     }
     return sum;
   }
 
 }

このときのDetailsはひとつのList<Detail>だけを属性にします。

//* 関連 
//- 
//- 

* 参考 [#ped262e5]
- [[実践的な設計って、なんだろう？(slideshare)>http://www.slideshare.net/masuda220/ss-34813564]]
- [[いまさら聞けない「オブジェクト指向設計の3つのコツ」～オブジェクト指向設計問題解説>http://codeiq.hatenablog.com/entry/2013/08/26/155959]]
- [[ルール8：ファーストクラスコレクション - Strategic Choice>http://d.hatena.ne.jp/asakichy/20090620/1245448922]]