全再利用の原則（CRP）をわかりやすく解説

全再利用の原則（CRP）とは？
考えが生まれた背景
CRPのメリット
具体的な例
CRPとISP（インターフェース分離の原則）の関係
まとめ

全再利用の原則（CRP）とは？

全再利用の原則（CRP: Common Reuse Principle）は、ソフトウェア設計における重要な原則の一つで、「同じモジュールに含まれるクラスは、必ず一緒に再利用されるべきである」という考え方です。
簡単に言うと、「一緒に使われる可能性があるクラスは1つのモジュールにまとめ、一緒に使われないクラスは分けるべき」というルールです。これにより、必要のないコードや依存関係を取り込むことを防ぎ、モジュールを効率的に利用できるようになります。

考えが生まれた背景

ソフトウェア開発では、以下のような問題が頻繁に発生していました

必要のない依存関係を抱える

再利用したいモジュールに、実際には必要のないコードやクラスが含まれている場合、それらを含めてすべての依存関係を取り込む必要があります。
これにより、コードが重くなり、保守や拡張が困難になります。

冗長なコードの取り込み

モジュールが不要な機能を持っている場合、それらを再利用時に一緒に取り込むことで、冗長なコードがシステムに混在します。

保守性の低下

不要なクラスや依存関係が多いモジュールでは、変更の際に無関係な部分にも影響が及び、保守性が低下します。

全再利用の原則（CRP）は、これらの問題を解決するために提唱されました。関連性の高いクラスのみを1つのモジュールにまとめることで、再利用性を高めつつ、無駄を削減する設計を目指します。

CRPのメリット

必要最低限の依存関係で済む

モジュール内のクラスがすべて再利用に関連しているため、再利用時に必要のない依存関係を取り込むことがありません。

冗長性の削減

再利用するコードがコンパクトになり、不要なコードの混在を防ぐことで、システムが軽量化されます。

保守性の向上

モジュール内のクラスが明確に関連付けられているため、変更が必要な場合でも影響範囲を限定できます。
再利用性が高まることで、新しい機能の追加や既存機能の変更が容易になります。

具体的な例

NGな例：再利用が難しいモジュール

以下のように、認証、メール送信、レポート生成が1つのモジュールにまとめられている設計を考えます。

Java

class UtilityModule {
    public void authenticateUser() {
        // ユーザー認証ロジック
        System.out.println("Authenticating user...");
    }

    public void sendEmail(String message) {
        // メール送信ロジック
        System.out.println("Sending email: " + message);
    }

    public void generateReport() {
        // レポート生成ロジック
        System.out.println("Generating report...");
    }
}

問題点：

1つのモジュールに認証、メール送信、レポート生成というまったく異なる責任が詰め込まれています。
「ユーザー認証」だけを再利用したい場合でも、このモジュール全体を取り込む必要があります。
メール送信やレポート生成のコードが不要であっても、それらの依存関係までシステムに取り込むため、コードが無駄に肥大化します。

OKな例：再利用性の高いモジュール

CRPを適用して、関連性の高いクラスを1つのモジュールにまとめ、責任ごとにモジュールを分割します。

認証モジュール：ユーザー認証に特化

Java

class UserAuthentication {
    public void authenticate(String username, String password) {
        // ユーザー認証ロジック
        System.out.println("Authenticating user: " + username);
    }
}

class PasswordValidator {
    public boolean isValid(String password) {
        // パスワード検証ロジック
        return password.length() >= 8;
    }
}

ポイント： 認証に関連するクラスだけをこのモジュールにまとめました。
メリット： 認証機能だけを再利用したい場合、このモジュールだけを取り込めば十分です。

メール送信モジュール：メール送信に特化

Java

class EmailService {
    public void sendEmail(String recipient, String message) {
        // メール送信ロジック
        System.out.println("Sending email to: " + recipient + " with message: " + message);
    }
}

ポイント： メール送信に特化しているため、他の機能の影響を受けずに再利用できます。

レポート生成モジュール：レポート生成に特化

Java

class ReportGenerator {
    public void generateReport(String reportType) {
        // レポート生成ロジック
        System.out.println("Generating report: " + reportType);
    }
}

ポイント： レポート生成のみに特化しており、他の機能と依存関係がありません。

改善の結果

各モジュールが1つの責任に特化しているため、必要な部分だけを再利用できます。
例えば、「認証機能が必要なプロジェクト」では、認証モジュールのみを取り込めばよく、不要なメール送信やレポート生成のコードを含める必要がありません。
これにより、再利用時のコードの軽量化と保守性の向上が実現します。

CRPとISP（インターフェース分離の原則）の関係

ISP（インターフェース分離の原則）
「クライアントは、使用しないメソッドを持つインターフェースに依存してはならない」という原則です。
ポイント：クライアントが本当に必要な機能だけを提供するインターフェースを設計する。
CRP（全再利用の原則）
「同じモジュール内のクラスは、必ず一緒に再利用されるべき」という原則です。
ポイント：モジュール内のクラスが関連性を持ち、一緒に使われることを前提に設計する。