今回の話はオブジェクト指向についてなので長いです。ごめんなさい。

継承は、サブクラスがスーパークラスの実装に依存してしまう。「Effective Java 第3版」では、HashSetを継承したケースで起こる問題を記載している。

HashSetのaddAllメソッドが内部でaddメソッドを使っています。そのためサブクラスで”要素を追加した件数をカウント”するってなった場合に、addメソッドをオーバーライドして、スーパークラスのaddAllメソッドを安易に呼び出すと不具合が起きる場合がある。（この本のサンプルはネットにゴロゴロ落ちています）

メソッドをオーバーライドしない場合も、スーパークラスが新リリースによりサブクラスで独自に定義したのメソッドと、同名のメソッドを定義する可能性もあります。（自分がスーパークラスの実装者でない場合）
スーパークラスの変数にアクセスしたいなどとなった場合はアクセス修飾子がprivateであってはいけない。→ホワイトボックス再利用
スーパークラスの実装の変更がサブクラスにも影響が出る。

そのためこのクラスのメソッド使いたいから継承しようって考えるのでなく、コンポジションを利用しようと考えます。

コンポジション

コンポジションは利用したクラスのオブジェクトを変数で保持しておいて、そのオブジェクトを利用する方法です。

これならば、カプセル化の概念を破壊せずに各クラスは各クラスの責務に向き合うことができる

今回は既存のメール送信クラスがあるとして、新しく予約システムの作成をする。予約完了時にメール送信するような仕組みにしたいので、予約クラスはメールクラスを継承するのでなく、コンポジションを使って利用します。

public class Mail {

    private final String to;

    private final String from = "admin@company.com";

    public Mail(String to){
        this.to = to;
    }

    public void send(String str){
        System.out.println(
                "to" + to + " / " +
                "from" + from + " / " +
                "「" + str + "」"
        );
    }
}

メールクラスは指定の宛先に、渡されたメールの内容を送信するだけです。

予約クラスはこのsendメソッドを利用して予約時にメール送信を試みます。

public class Reserve{
    
    private final Mail mail;

    private final int roomNo;

    private boolean done = false;

    public Reserve(int roomNo){
        this.mail = new Mail("user@company.com");
        this.roomNo = roomNo;
    }

    public void getReserve(){
        // 予約処理の実施
        this.done = true;
        System.out.println("予約の完了");

        //　予約できたらメールで連絡する
        this.mail.send(this.roomNo + "予約しました");
    }
}

Mailクラスを変数として保持することで、予約が完了したらMailクラスのsendメソッドを利用しています。以下のようにして利用します。

public void test(){
        Reserve reserve = new Reserve(12);
        reserve.getReserve();
    }

予約の完了
touser@company.com / fromadmin@company.com / 「12予約しました」

ちなみにコンポジションと集約はとても似ています。

http://mylifeinventory.blog.fc2.com/blog-entry-27.html

「オブジェクト指向のこころ」では

保持されているものが保持しているものの一部
- 自動車とそれを構成するエンジン
独立して存在できる何かのコレクションがある
- 空港とそこに駐機されている飛行機

最初の例がコンポジションで、2番目が集約、と説明されています。これはGofと逆。

デザインパターン

デザインパターンをカタログとして捉えてしまうと、パターンが目的になってしまい、オブジェクト指向の理解から遠ざかってしまうような気がしています。

そのため今回はコンポジションと集約に目線を向けてデザインパターンを確認します。

アダプターパターン

アダプターパターンは継承を行うパターンと委譲を行うパターンがあります。今回は委譲を行うパターンについて説明します。

アダプターパターンはインターフェースに互換性のないクラス同士を結び付けます。

ポリモーフィズムで振舞を柔軟に変更している場合、互換性のないインターフェースを実装したクラスを利用したくなっても、インターフェースが合致していないため利用できません。

そういった時にインターフェースを派生させた新規クラスで、利用したいクラスをラップすることでインターフェースを適合させます。

例

データベースインターフェースを実装して、OracleとMySqlクラスを作成します。

public interface Database {
    void connect();
    void setup();
}

public class Oracle implements Database {
    @Override
    public void connect() {
        System.out.println("Oracleデータベースに接続しました。");
    }

    @Override
    public void setup() {
        System.out.println("Oracleのセットアップが完了しました。");
    }
}

public class MySql implements Database{

    @Override
    public void connect() {
        System.out.println("MySqlデータベースに接続しました。");
    }

    @Override
    public void setup() {
        System.out.println("MySqlのセットアップが完了しました");
    }
}

ここまでは問題ないです。しかし次のリリースでPostgreにも対応する必要が出てきました。Postgre関連のクラスを別のチームが作っていたのですが、実装しているインターフェースも名前も適合しませんでした。

public interface DataBaseConnection {
    void access();
    void init();
}

/**
 * 既存のPostgreのクラスはそもそも実装するインターフェースもメソッド名も違う。
 * そのためDatabaseインターフェースに適合できないのでポリモーフィズムが利用できない。
 */
public class Postgre implements DataBaseConnection{
    @Override
    public void access() {
        System.out.println("Postgreデータベースに接続しました。");
    }

    @Override
    public void init() {
        System.out.println("Postgreの環境セットアップが完了しました。");
    }
}

これでは利用ができませんので、Adapterを作成してインターフェースを適合させます。

/**
 * インターフェースもメソッド名も適合していないPostgreクラスのアダプタークラス
 * Databaseインターフェースを実装して、メソッドの実装はPostgreクラスのオブジェクトに委譲することで
 * PostgreクラスをDatabaseインターフェースのものとして利用する
 */
public class PostgreAdapter implements Database{

    // 変数としてPostgreオブジェクトを保持しておく
    private final Postgre postgre;

    public PostgreAdapter(){
        this.postgre = new Postgre();
    }

    @Override
    public void connect() {
        this.postgre.access();
    }

    @Override
    public void setup() {
        this.postgre.init();
    }
}

アダプタはDatabaseインターフェースを実装して、実装は既存のPostgreクラスのメソッドを利用します。これならば既存のPostgreクラスを一切修正することなく利用できます。

public class Client {

    public void use(){

        // Database型のオブジェクトを使う
        Database database = new Oracle();
        database.connect();
        database.setup();

        database = new MySql();
        database.connect();
        database.setup();

        // Postgreだけインターフェースが適合しないためエラー
        // database = new Postgre();

        // そこでadapterを利用する
        database = new PostgreAdapter();
        database.connect();
        database.setup();
    }
}

Oracleデータベースに接続しました。

Oracleのセットアップが完了しました。

MySqlデータベースに接続しました。

MySqlのセットアップが完了しました

Postgreデータベースに接続しました。

Postgreの環境セットアップが完了しました。

デコレーターパターン

デコレーターパターンは、継承を使わずにオブジェクトに新たな責務を与えるパターンです。

例えば既存の印刷処理に対してヘッダー情報とフッター情報の出力を追加したい場合に、印刷処理を行うクラスを継承してヘッダーを出力するクラスを作ったりするのではなく、既存の印刷処理をヘッダー出力クラスから委譲することで、ヘッダー出力と既存の印刷処理を実施できるようにします。

以下のポイントがあります

既存の印刷処理クラスに手を付けることはしません
責務は取り外し可能
- ヘッダーとフッターの出力は取り外せる
サブクラス化をしてクラス階層を莫大に増やすことをしない

例

Printerはシンプルに与えられた文字列をプリントするクラスで、Printインターフェースを実装します

public interface Print {
    void print(String message);
}

public class Printer implements Print{

    @Override
    public void print(String message) {
        System.out.println(message);
    }
}

ここでヘッダーとフッターも出力できるようにしたいとなりました。しかしPrinterクラスの印刷処理は、他のシステムからも利用されているため修正することはできません。

そこでデコレータークラスを作成してPrinterクラスの責務を動的に追加します。

/**
 * Printオブジェクトの責務を増やすためのクラス
 *
 * 既存のPrinterクラスを継承せずに処理の拡張をすることが目的です
 *
 */
public abstract class PrintDecorator implements Print {

    private Print print;

    public PrintDecorator(Print print){
        this.print = print;
    }

    public void callPrint(String str){
        if(Objects.nonNull(this.print)){
            this.print.print(str);
        }
    }
}

ヘッダー出力クラスを作成します。

public class PrintHeader extends PrintDecorator{

    public PrintHeader(Print print) {
        super(print);
    }

    @Override
    public void print(String message) {
        System.out.println("ヘッダーの出力を行う");
        callPrint(message);
    }
}

フッターの出力クラスも作成します

public class PrintFooter extends PrintDecorator{

    public PrintFooter(Print print) {
        super(print);
    }
    @Override
    public void print(String message) {
        callPrint(message);
        System.out.println("フッターの出力を行います");
    }
}

これらデコレータークラスは取り外し可能です

@Test
    public void test_ヘッダーフッター出力ができる(){
        Print printer = new Printer();
        printer = new PrintHeader(printer);
        printer = new PrintFooter(printer);
        printer.print("大変いつもお世話になっております");
        // まずFooter#printでFooter#callPrintが呼ばれる
        //   Print#printが呼ばれる（ここではHeaderが設定されているのでHeader#printが呼ばれる)
        //   　　Header#printではヘッダー情報を出力して、Header##callPrintが呼ばれる
        //   　　　　Print#printが出力される(ここは既存のPrinter#print)
        // 最後にFooterの出力が行われる
    }

ヘッダーの出力を行う

大変いつもお世話になっております

フッターの出力を行います

フッターが不要ならばフッターを外せばいいだけです。

デコレータークラスがPrintインターフェースを実装しているので、ポリモーフィズムによってその実装クラス（HeaderとFooter）のprintメソッドが問題なくコールされます。

ブリッジパターン

ブリッジパターンは、抽象と実装を分離してそれぞれ独立して変更できるようにするパターンです。例えばJDBC（抽象）で利用するDriver（実装）を変更するだけで、接続するデータベースをOracle、Postgreなど簡単に切り替えることができます。→Class.forNameで登録しているやつ

例

OracleとPostgreに接続する例を考えてみます。まずはAPIを提供するクラスです

public abstract class Access {

    protected Driver dirver;

    public Access(Driver driver){
        this.dirver = driver;
    }

    abstract void connect(String url);
}

public final class DataAccess extends Access{

    public DataAccess(Driver driver) {
        super(driver);
    }

    @Override
    void connect(String url) {
        this.dirver.connect(url);
    }
}

Driverが実装の詳細ですが、APIを提供するだけのクラスでは実装の詳細については関与しません。

Driverインターフェースです

public interface Driver {
    void connect(String url);
}

Postgre用のDriver実装クラスです

public class PostgreDriver implements Driver{

    @Override
    public void connect(String url) {
        System.out.println("Postgreに接続しました" + url);
    }
}

この時点で利用することができます。

抽象と実装の橋渡しであるAccessクラスは、指定された実装クラスを利用します

Access access = new DataAccess(new PostgreDriver());
access.connect("postgre:0.0.0.0:5432");

Postgreに接続しましたpostgre:0.0.0.0:5432

OracleのDriverも追加してみますが、アダプターパターンと混ぜてみます。適合しないインターフェース

public interface ODriver {
    void connect(String url, String info);
}

public class OracleDriver implements ODriver{
    @Override
    public void connect(String url, String info) {
        System.out.println("Oracleに接続しました" + url + info);
    }
}

アダプターを利用してDriverとして利用します

public class OracleDriverAdapter implements Driver{

    private OracleDriver driver;

    public OracleDriverAdapter(){
        this.driver = new OracleDriver();
    }

    @Override
    public void connect(String url) {
        this.driver.connect(url,"read setting");
    }
}

Access access = new DataAccess(new PostgreDriver());
access.connect("postgre:0.0.0.0:5432");

access = new DataAccess(new OracleDriverAdapter());
access.connect("oracle:0.0.0.0:5432");

Postgreに接続しましたpostgre:0.0.0.0:5432

Oracleに接続しましたoracle:0.0.0.0:5432read setting

オブジェクト指向について

ブリッジパターンとアダプターパターンは似ています。実装の詳細を別のオブジェクトに委譲している点は、ほとんど同じだと言えるでしょう。

ブリッジパターンはインターフェースと実装を分けて設計して、ロジックの取替を容易にすることでクラスが増えていくのを防止できます。
アダプターパターンは既存の機能を、新しいシステムやインターフェースで使いたい時に動作させる目的です。

今回はあえて混ぜて使ってみたので違いが割とハッキリしました。

デザインパターンを利用しようとした時、どのパターンに落とし込むかを考える前に、継承をするという考えを捨ててプログラミングをしていくと、自然とパターンに当てはまっているかもしれません。

そして自然とパターンに落とし込むには、ポリモーフィズムの理解が必須だということが言えると思います。

今まで見てきたパターンは全てポリモーフィズムが働いています。

つまりデザインパターンでオブジェクト指向を理解するには、ポリモーフィズムと委譲を上手に利用することが重要ですね。

継承よりもコンポジションを選ぶのとデザインパターンの話