コードライブラリをスタンドアロンのPHPクラスとしてリリースするとします。次に、誰かがそのライブラリのバージョン1.0をアプリケーションで使用します。後で、ライブラリのバージョン2.0をリリースしました。同じ人が、何らかの理由で、新しいリリースとの下位互換性を壊したため、アプリケーションで1.0と2.0の両方を並べて使用する必要があります。
クラス名が異なる場合は、名前の競合がないため、両方を含めてインスタンス化するのは簡単です。しかし、クラス名が同じに保たれていると、問題が発生します。
include /lib/api-1.0/library.php;
$oldlibary = new Library();
include /lib/api-2.0/library.php;
$newlibrary = new Library();
両方の名前の2つのクラスをロードできないため、これは機能しませんLibrary
。別の開発者が提案した代替案の1つは、名前空間を使用することでした。以下が機能するはずです。
namespace old {
include /lib/api-1.0/library.php;
}
namespace new {
include /lib/api-2.0/library.php;
}
$oldlibary = new old\Library();
$newlibrary = new new\Library();
残念ながら、これはあまりスケーラブルではありません。これは2インスタンスの状況で機能しますが(できれば、そもそも使用する必要はありません)、3、4、5、またはそれ以上のインスタンスにスケーリングするには、追加の名前空間を定義する必要がありますそもそもこれらの名前空間を使用していない場合は、不要なコードがたくさんあります。
では、名前空間を動的に作成し、ファイルを含め、そのファイルに含まれるクラスを一意の名前の変数でインスタンス化する方法はありますか?
もう少し説明を追加しましょう...
いくつかのCMSプラットフォーム用のプラグイン/モジュールを構築する他の開発者が使用するライブラリのセットを構築しています。理想的には、誰もが常に最新バージョンのライブラリを使用することを保証できませんが、新しいバージョンが利用可能になったときにエンドユーザーが常にモジュールをアップグレードすることを保証することはできません。
私が使用しようとしているユースケースは、エンドユーザーが2人の異なる開発者によって2つの異なるモジュールをインストールする場合です。それらをAppleとOrangeと呼びます。どちらのモジュールも私のライブラリのバージョン1.0を使用しています。これは素晴らしいことです。一度インスタンス化することができ、両方のコードセットが機能の恩恵を受けることができます。
後で、このライブラリにマイナーパッチをリリースします。1.xブランチとの下位互換性を壊さないため、バージョン1.1です。Appleの開発者はすぐにローカルバージョンを更新し、システムの新しいエディションをプッシュします。Orangeの開発者は休暇中で、気にしません。
エンドユーザーがAppleを更新すると、彼女は私のライブラリの最新のメンテナンスリリースを入手します。これはメンテナンスリリースであるため、バージョン1.0を完全に置き換えるのが安全であると想定されています。そのため、コードは1.1をインスタンス化するだけであり、開発者がリリースを更新することを気にしない場合でも、 Orangeはメンテナンスパッチの恩恵を受けます。
後で、何らかの理由でFacebookにフックを追加するようにAPIを更新することにしました。新しい機能とAPI拡張機能はライブラリに関して大きく変更されるため、バージョンを2.0に上げて、すべての状況で下位互換性がない可能性があることを示すフラグを立てます。もう一度、Appleは入って、彼のコードを更新します。何も壊れませんでした。彼は自分のフォルダにある私のライブラリを/lib
最新バージョンに置き換えただけです。 オレンジは、ピエロになるために学校に戻ることを決心し、モジュールの保守を停止したため、更新は行われません。
エンドユーザーが新しいリリースでAppleを更新すると、彼女は自動的に私のライブラリのバージョン2.0を取得します。しかし、オレンジは彼のシステムにすでにFacebookフックを追加するコードを持っていたので、2.0がデフォルトで彼のライブラリにロールインされた場合、競合が発生します。そのため、完全に置き換えるのではなく、 Apple用に2.0を一度インスタンス化し、 Orangeに付属の1.0バージョンを並べてインスタンス化して、適切なコードを使用できるようにします。
このプロジェクトの全体的なポイントは、サードパーティの開発者が信頼できるものに依存することなく、私のコードに基づいてシステムを構築し、必要なときにコードを更新できるようにすることです。エンドユーザーにとって何も壊れてはなりません。他の誰かのシステム内で使用するときにライブラリを更新することは、すべてのクラス参照を調べて変更するのではなく、単純なファイル置換である必要があります。