コンポーネントの凝集性に関する原則　閉鎖性共通の原則とは?

背景

バグ修正や機能変更の際、時間がかかる作業の一つに「変更がどのクラスに影響するかの調査」があります。この作業で、私自身、大きなストレスを感じています。
閉鎖性共通の原則は、このストレスを軽減してくれる頼もしい原則です。

閉鎖性共通の原則とは?

私が読んだ書籍では、以下のように定義されていました。
「同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。」（ロバート・C・マーチン, 2018, 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』, 翔泳社, p.138）

この原則は、コンポーネントを変更する理由は複数あるべきではないという考え方に基づいています。
似た原則としてSOLIDの「単一責任の原則」があります。単一責任の原則は「クラスに対する変更理由は一つであるべき」というものですが、これをコンポーネントレベルに拡張したものが閉鎖性共通の原則です。

違反ケース

同じ理由や同じタイミングと言われても、抽象的過ぎて理解できないので、具体的な違反ケースとともに、この原則の重要性を紹介していきたいと思います。

別の理由で変更されるクラスが同じコンポーネントにまとめられているケース

例として、顧客情報管理機能と注文管理機能が同じコンポーネントにまとめられているケースを考えます。この2つの機能は異なる目的で使用され、変更理由も異なることが想定されます。

問題点:
顧客情報管理機能に変更があっても、注文管理機能には変更がない場合でも、同じコンポーネントにあるため両方を一緒にデプロイする必要があります。これにより、不要なテストが発生したり、まとまっていることでリリースに時間がかかるという問題が生じる可能性があります。

同じ理由で変更されるクラスが別コンポーネントに分かれてしまっているケース

次に、購買処理と在庫管理処理が別々のコンポーネントに分かれているケースを考えます。購買処理と在庫管理処理は密接に関連しており、商品の購入時に購買処理が動作し、在庫管理処理が在庫を減らす必要があります。

問題点:
同じ理由で変更が必要な処理が異なるコンポーネントに分かれていると、修正が発生した場合に複数のコンポーネントに対して整合性を取る必要が出てきます。これにより、コードの冗長性や管理の複雑さが増し、保守性が低下します。

閉鎖性共通の原則に違反することで、上記のような問題が発生することが考えられます。

まとめ

閉鎖性共通の原則は、コンポーネントの凝集性を高め、保守性を向上させる上で役に立つ指針です。もちろん、サービスやシステムの状況に応じて、保守性や再利用性をどちらを優先するかは変わってくるため、最適なアーキテクチャは一概に決められません。
しかし、この原則を設計の一つの基準として取り入れることで、効率的な開発に役立つと思うので、活用していきたいと思います。