デザインパターン # アダプターパターン-jsチュートリアル-php.cn

デザインパターン # アダプターパターン

WBOY

リリース： 2024-07-18 01:27:31

オリジナル

1002 人が閲覧しました

Design Pattern # Adapter Pattern

過去数週間にわたって、PubSub や Singleton などのトレンドのデザインパターンのいくつかを共有してきました。今日は、このシリーズのもう 1 つの記事を共有するつもりですが、以下にコメントして、次にどのデザインパターンを取り上げるべきか教えてください。

アダプターのパターン

アダプターパターンは、互換性のないインターフェイスを持つオブジェクトの連携を可能にする構造設計パターンです。これは、ソースコードを変更せずに既存のクラスを他のクラスと連携させたい場合によく使用されます。このパターンは、既存のクラスのインターフェイスが必要なインターフェイスと一致しない場合に特に便利です。

実際のケースのシナリオ

実際の例を考えてみましょう。あなたは、サードパーティのビデオプレーヤーをアプリケーションに統合する任務を負っています。ただし、ビデオプレーヤーの機能は異なり、アプリケーションが期待するものとは異なるメソッドインターフェイスを持っています。この場合、アダプターパターンを使用してビデオプレーヤーのラッパークラスを作成し、サードパーティのコードを既存のアプリケーションコードと互換性を持たせることができます。

この場合に使用するコードは次のとおりです:

// Adapter class
class VideoPlayerAdapter {
    constructor() {
        this.externalPlayer = new ThirdPartyVideoPlayer({
            // some configuration
        });
    }

    play() {
        const video = this.externalPlayer.getVideo();
        this.externalPlayer.playVideo(video, {
            // additional parameters
        });
    }
}

// Your application code
class Application {
    constructor() {
        this.videoPlayer = new VideoPlayerAdapter();
    }

    start() {
        // Play video using your application code
        this.videoPlayer.play();
    }
}

ログイン後にコピー

上記のコードを分解してみましょう:

ThirdPartyVideoPlayer は、アプリケーションが使用する仮想の外部ライブラリです。ただし、そのインターフェイスはアプリケーションと互換性がない可能性があります。
VideoPlayerAdapter はアダプタークラスです。 ThirdPartyVideoPlayer をラップします。アダプターのインターフェースはアプリケーションと互換性があります。アダプターの play() メソッドが呼び出されると、内部的に ThirdPartyVideoPlayer で必要なメソッドが呼び出されます。
アプリケーションはアプリケーションコードです。 VideoPlayerAdapter のインスタンスを作成し、それを通常のビデオプレーヤーであるかのように使用します。アダプターで play() メソッドを呼び出すと、アダプターはそれを ThirdPartyVideoPlayer への適切な呼び出しに変換します。

この方法では、Application クラスは ThirdPartyVideoPlayer の動作について何も知る必要がありません。 ThirdPartyVideoPlayer を別のライブラリに置き換える必要がある場合は、新しいアダプターを作成するだけで済みます。Application クラスは同じままで構いません。これがアダプタパターンの主な利点です。つまり、アプリケーションコードをサードパーティライブラリの詳細から切り離します。

アダプターパターンとファサードパターンの違い

アダプターパターンとファサードパターンは似ているように見えるかもしれませんが、異なる目的を果たし、異なるコンテキストで使用されます。

目的:
- アダプターパターン: アダプターパターンの主な目的は、互換性のない 2 つのインターフェイスを相互に互換性のあるものにすることです。これにより、異なるインターフェイスを持つ既存のクラスを、あたかも別のインターフェイスを実装したかのように使用できるようになります。
- ファサードパターン: ファサードパターンの主な目的は、複雑なサブシステムに簡素化されたインターフェイスを提供することです。サブシステムの複雑さを隠し、サブシステムを使いやすくする高レベルのインターフェイスを提供します。
使用法:
- アダプターパターン: アプリケーション内の既存のクラスまたはインターフェイスと一致しない新しいクラスまたはライブラリを統合する必要がある場合に使用されます。アダプターパターンは、特定のインターフェイスを予想されるインターフェイスに適応させることに関するものです。
- ファサードパターン: 複雑なサブシステムとの対話を簡素化したい場合に使用されます。ファサードは、システムと対話するための簡単な方法を提供し、その複雑さを隠します。
デザイン:
- アダプターパターン: 通常、クライアントが期待するインターフェイスを実装し、呼び出しを適応されたクラスに変換する新しいクラス (アダプター) の作成が含まれます。
- Facade パターン: クライアントに簡略化されたメソッドを提供する Facade クラスの作成が含まれ、多くの場合、サブシステムから複数の機能が集約されます。