home wiki.fukuchiharuki.me
Menu
Top/設計パターン/ファーストクラスコレクション 
#author("2018-05-11T06:09:24+00:00","default:haruki","haruki")
* キーワード [#i5588508]
- 集約
- コレクション
-- 配列
-- リスト

* 何か [#ec18191a]

 中間管理職
 取り纏め役

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

たとえば伝票「Slip」と明細「Detail」があるとき、複数の「Detail」を扱うための「Details」を設け、「Slip」、「Details」、「Detail」の関係を設計します。

#ref(first-collection.png,center)

* なぜか [#pf3aa25b]

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

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

コレクションに対する処理を集約する側に寄せると、集約する側をこれら問題のたまり場にしてしまいます。そこで''コレクションに対する処理をするためだけのクラス''を独立させ、これら問題にあたらせます。
コレクションに対する処理を集約する側に寄せると（上記の例で言えば明細「Slip」）、集約する側をこれら問題のたまり場にしてしまいます。そこで''コレクションに対する処理をするためだけのクラス''を設けることを考えます。

* どのように [#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]]