閉鎖性共通の原則（CCP）とは？
閉鎖性共通の原則（CCP: Common Closure Principle）は、ソフトウェア設計における重要な原則の一つで、「変更の理由が同じクラスやモジュールをグループ化するべき」という考え方です。
簡単に言うと、「一緒に変更される可能性があるものは、1つのモジュールやパッケージにまとめるべき」というルールです。これにより、変更時の影響範囲を限定し、保守性を向上させます。
考えが生まれた背景
ソフトウェア開発の現場では、次のような課題が頻発していました
変更の影響が広がる
- ある機能を変更すると、複数のモジュールやクラスにわたって修正が必要になることがあります。
- これにより、変更のコストが増大し、予期せぬバグを生むリスクが高まります。
関連するコードが分散している
- 同じ理由で変更されるはずのコードが異なる場所に分散していると、変更箇所を見つけるのが困難になります。
- 修正漏れが発生する可能性が高くなり、保守性が低下します。
チーム開発の混乱
- 関連する変更が複数の開発者にまたがる場合、変更内容の調整が難しくなり、開発効率が低下します。
閉鎖性共通の原則は、これらの課題を解決するために提唱されました。一緒に変更される可能性が高いコードを1つのモジュールやパッケージにまとめることで、変更時の影響を最小限に抑える設計を目指します。
CCPのメリット
変更の影響を最小化
- 変更が必要なコードが1つのモジュールにまとめられていれば、変更箇所を特定しやすくなります。
- 他のモジュールへの影響を最小限に抑えられるため、バグのリスクを軽減できます。
保守性が向上
- 関連するコードが一箇所にまとまっているため、修正や機能追加が容易になります。
- チーム内での変更内容の共有や調整がスムーズに進みます。
開発効率の向上
- 関連する変更をまとめて行えるため、開発スピードが向上します。
- 冗長なコードや複数箇所での同じ修正作業が不要になります。
具体的な例
NGな例：関連するコードが分散している場合
例えば、ECサイトの注文機能を考えます。以下のように、注文処理に関するロジックが複数のモジュールに分散しているとします。
OrderValidator：注文の検証を行うクラスOrderProcessor：注文の処理を行うクラスOrderNotifier：注文完了通知を送るクラス
もし、「注文にクーポンを適用するロジックを追加する」という要件が発生した場合、上記3つのクラスをそれぞれ修正しなければなりません。このような設計では、変更の影響が広がりやすくなります。
OKな例：関連するコードを1つのモジュールにまとめる
閉鎖性共通の原則を適用すると、以下のように設計を改善できます
Java
class OrderService {
public void validateOrder() {
// 注文の検証ロジック
}
public void processOrder() {
// 注文の処理ロジック
}
public void sendOrderNotification() {
// 注文完了通知のロジック
}
}
この場合、注文にクーポン適用機能を追加したい場合は、OrderService クラスだけを修正すれば済みます。
CCPとSRP（単一責任の原則）の類似点
- SRP（単一責任の原則）
クラスやモジュールは「1つの責任」に集中すべき。1つの理由でしか変更されないように設計します。
単一責任の原則とは？初心者でも分かる簡単解説
単一責任の原則（SRP）を初心者向けに解説。背景や具体例、メリット、課題と対策を丁寧に説明し、実践をサポートします！
www.takatechskill.com
2025.01.05
- CCP（閉鎖性共通の原則）
変更の理由が同じものを1つのモジュールにまとめるべき。
共通点
どちらも「変更」を中心に設計を考える点で共通しています。SRPは個々のクラスの責任範囲に焦点を当て、CCPは関連するクラスやモジュールのグループ化に焦点を当てています。
CCPの課題
適切な設計の判断が難しい
- 「どのコードが同じ理由で変更されるのか」を見極めるのは簡単ではありません。
- 設計の経験や変更履歴の分析が必要です。
モジュールの肥大化
- 関連するコードを1つのモジュールにまとめすぎると、モジュールが大きくなり、管理が難しくなる可能性があります。
まとめ
閉鎖性共通の原則（CCP）は、「変更の理由が同じコードを1つのモジュールにまとめるべきという設計の基本原則です。これにより、変更時の影響範囲を限定し、保守性や開発効率を向上させることができます。
コメント