私が考えるファーストクラスコレクションを定義しておく意味や意義みたいなもの

私の考え

私は、ドメインオブジェクトのコレクションには常にファーストクラスコレクションを定義しておくと良いと考えています。

例えば、List<DomainObject>という生の配列をクライアントコードに操作させる場合、あちこちのクライアントコードに同じ操作が（しかもちょっとずつ違うやり方で）書かれているという状況を招きかねないためです。

特に別の技術者が参画してきたときはまだコードの書き方を真似しきれないはずですから、その状況を引き起こしやすいでしょう。

例えば、List<DomainObject>を許した場合

どういうことがおきるでしょうか。

同じ操作なのに書き方が違うものがあちこちのクライアントコードに散在しているとします。 影響をうけうるクライアントコードをすべて特定するのが手間です。 また、特定できたとして書き方が違うと本当にそこにも変更を反映すべきなのかどうか迷ってしまうかもしれません、それを調べるコストがもったいないと感じてしまいます。

また、別のケースとしては、属性に変更があったから操作に影響が出たのでとある処理の修正が必要といったときに、その変更が発散していろんなクライアントコードに波及してしまいます。

一方で、ファーストクラスコレクションを定義してそこに操作を集約しておくとどうなるか

操作を実装されるコード間の距離が物理的に近いのでそのコレクションを操作する時の書き方の統一感を期待できますし、何かを操作するコードが1箇所であることを期待できるので、変更の発散がかなり抑制できるはず1です。

開発に関わるエンジニアが少数しかおらず、その入れ替わりがないのであればまだ操作が存在しないコレクションまでファーストクラスコレクションとするのは短期的にはコスパは悪いかもしれません。

しかし、先述の理由から中長期的にはコスパ良いと私は信じています。

なお、ファーストクラスコレクションに限りませんが、私の経験則では、後からリファクタリングして対応するという方針にする場合、似たような処理（分岐）が２箇所で出てきたら黄信号（リファクタリングの必要が高い）、３箇所になったら赤信号（このタイミングでリファクタリングしておかないと高い確率でまずい状況を引き起こす）って感じています。

  1. 運が良ければ完全になくせるかもしれませんが、変更はどうしても波及するものです。しかし、その影響度合いを小さくすることは可能だと考えています。↩