低凝集なコレクション処理をファーストクラスコレクションで最適化する方法

ソフトウェア開発において、コードの凝集性はメンテナンス性や可読性に大きな影響を与えます。特に複数のオブジェクトを管理するコレクション処理においては、凝集性の低い設計がバグの温床になることもあります。

本記事では、低凝集なコレクション処理の解決策として「ファーストクラスコレクション」を紹介します。

具体的なサンプルコードはC#で説明していますが、このアプローチは他のプログラミング言語にも応用可能です。

ファーストクラスコレクションとは？

ファーストクラスコレクション（First Class Collection）は、特定のコレクション（リストやセットなど）を専用のクラスとして扱う設計手法です。

このクラスはコレクションに対する操作（追加、削除、検索、集計など）を含み、コレクションの管理や操作に関わるロジックを一箇所に集約します。ファーストクラスコレクションの導入により、コレクションを直接操作することなく、専用のクラスを介して一貫した方法で管理できるようになります。

この手法を用いると、凝集性が高まるため、コードのメンテナンス性や拡張性が向上します。また、コードが意図する動作がより明確になり、バグの発生率を低減できます。

低凝集なコレクション処理の問題点

低凝集なコレクション処理とは、コレクションに関する処理が複数のクラスやメソッドに分散している状態を指します。この場合、以下のような問題が発生しやすくなります。

可読性の低下: コレクションに関する操作が分散しているため、どこで何をしているのかが分かりにくくなり、コードを理解するのに時間がかかります。
メンテナンス性の悪化: 処理が複数の場所に分散していると、修正や拡張を行う際に多くの箇所を変更する必要が生じ、バグの発生リスクが高まります。
バグの発生: 各処理が分散していると、同じコレクションに対する操作が一貫性を欠くことがあり、予期しない動作やデータの不整合が発生することがあります。
テストの難易度: コレクションに関する処理が複数の箇所に存在する場合、特定の機能に対してテストを行うのが難しくなり、テストコードも複雑になりがちです。

例えば、RPGゲームでプレイヤーのインベントリを管理する際、アイテムの追加や削除、検索といった処理がプレイヤークラス内や他のクラスに分散していると、インベントリの整合性を保つのが難しくなります。ファーストクラスコレクションを導入することで、これらの問題を解消し、コードの一貫性と可読性を高めることができます。

悪い例のサンプルプログラム

以下のコードは、RPGゲームのプレイヤーのインベントリ管理における低凝集なコレクション処理の例です。この「悪い例」では、アイテムの追加、削除、検索といったインベントリに関する処理がPlayerクラスに分散しています。

// 悪い例：インベントリを単純なリストとして扱い、Playerクラスで直接操作
public class Player
{
    public List<Item> Items { get; set; } = new List<Item>();

    public void AddItem(Item item)
    {
        Items.Add(item);
    }

    public void RemoveItem(Item item)
    {
        Items.Remove(item);
    }

    public bool HasRareItems()
    {
        foreach (var item in Items)
        {
            if (item.Rarity == "Rare")
                return true;
        }
        return false;
    }
}

この例では、Itemsリストに関する操作がPlayerクラスに直接記述されています。これにより、インベントリの処理が分散し、メンテナンス性が低下しています。

例えば、レアアイテムの検索やアイテムの追加・削除処理が別々のメソッドにあり、新たなインベントリ機能が必要になるたびにPlayerクラスを修正しなければならなくなります。これが低凝集な設計の典型的な問題です。

ファーストクラスコレクションで解決する「良い例のサンプルプログラム」

以下のコードは、ファーストクラスコレクションを使用して凝集性を高めた「良い例」のサンプルプログラムです。インベントリに関する処理を専用のInventoryクラスに集約し、Playerクラスから分離しています。

// 良い例：Inventoryクラスを導入してコレクション操作を集約
public class Inventory
{
    private List<Item> _items = new List<Item>();

    public void Add(Item item)
    {
        _items.Add(item);
    }

    public void Remove(Item item)
    {
        _items.Remove(item);
    }

    public bool HasRareItems()
    {
        return _items.Any(item => item.Rarity == "Rare");
    }

    public IReadOnlyList<Item> GetAllItems()
    {
        return _items.AsReadOnly();
    }
}

public class Player
{
    public Inventory Inventory { get; private set; } = new Inventory();
}

この例では、Inventoryクラスがインベントリ管理のすべての処理を担っており、アイテムの追加・削除、レアアイテムの検索などを一箇所に集約しています。これにより、Playerクラスはインベントリ操作の詳細を意識せずに、シンプルにインベントリを利用できます。

コード改善によるメリット

凝集性の向上
インベントリに関する操作がInventoryクラスに集中しており、関連する機能を一箇所で管理できるため、コードの凝集性が向上します。
再利用性の向上
Inventoryクラスを他のクラスでも再利用できるようになり、拡張性が高まります。例えば、プレイヤー以外のキャラクターや敵にも同じインベントリ機能を適用することが可能です。
テストの簡易化
インベントリ機能をテストする際、Inventoryクラスだけを検証すればよく、テストがシンプルで管理しやすくなります。
メンテナンス性の向上
インベントリに関する処理がInventoryクラス内にまとまっているため、修正や機能追加が容易になり、コードの保守がしやすくなります。
バグの発生率低下
コレクション操作が集約されることで、複数箇所に分散している場合に発生しがちなデータ不整合やバグのリスクが低減します。