基本的に、この記事は、まだ名前空間を使用していないが、既存のコードを書き直すことを検討している人に役立ちます。
いくつかのプロジェクトを名前空間に翻訳し、それらを相互に接続しました。 プロジェクトはあまり大きくないので、週末に移行しました。
移行自体には特定の問題はありません。以下で必要なアクションのシーケンスを説明します。ほとんどの場合は日常的であり、ほとんどの作業を自動化する可能性があります...
アクションのシーケンス
翻訳する必要があるもの：クラス、インターフェース、定数、関数。
コードで探しているのは、 define（ '{CONSTANT_NAME}'）、クラス{CLASS_NAME}、インターフェイス{INTERFACE_NAME}、関数{FUNCTION_NAME}です。
次に、すべてのエンティティを紹介するテーブルをコンパイルします。エンティティの宣言は、前の手順で見つけました。 すべてのエンティティの宣言に必要な名前空間を追加します。
次に、コードを調べて、テーブルからエンティティへの呼び出しを変更し、必要な名前空間を呼び出しに追加します。もちろん、呼び出し元のコードがエンティティとは異なる名前空間を持っている場合に限ります。
実際、これで最も明らかな主要部分は終了します。
オートローダーがある場合は、ロード可能なクラスの名前空間を認識するようにオートローダーに教える必要があります。
コードがテストでカバーされている場合、それらを実行し、テストの実行中にエラーをキャッチします。 テストがない場合は、移行が複雑になることがあります。少なくともいくつかの手順を実行する必要があるため、少なくとも手でコードをテストする必要があります。
他に変更が必要なもの
名前空間を宣言することにより、グローバルエンティティへの呼び出しを中断します。たとえば、コードで新しい例外をスローする場合、名前空間に入るとこのコードは中断します。 Exceptionクラスはグローバル名前空間に存在するため、新しい\ Exceptionをスローするようにコードを変更する必要があります。 次の構造の検索でコードを確認できます。
新しいクラス、クラス::メソッド、クラスの拡張、インターフェイスの実装など
前の手順では、宣言されたエンティティのテーブルをコンパイルし、コードで呼び出しを検索しました。 コードに次の形式の構造が含まれる場合：
<?php
$class = 'Foo';
$class .= $bar;
$instance = new $class();
?>
それに応じて、そのようなコードも見つけて変更する必要があります。前の手順では修正されません。
それとは別に、「メンテナンス」コードまたは特定のコードの問題を強調する価値があります。たとえば、何らかのメタ構成に基づいて自動的に生成されたクラスがある場合、ジェネレーターにネームスペースを操作し、メタ構成自体を変更するように教える必要があります。
おわりに
既存のプロジェクトの名前空間への移行は、単純または複雑な場合があり、多くの場合、その中で使用される呼び出しの構造、テストでカバーされるコードの量、および「サービス」コードを変更するのがどれほど難しいかによって異なります。 これらすべての要因を考慮に入れて、複雑さを評価し、場合によっては、移行の価格が高いため、または機能の機能に対する要件が高いため、ネームスペースを使用したいという思いを捨てることさえできます。
また、コードが幅広い用途を対象としておらず、名前空間を入力したいという要望がプロジェクト間のクラス名の審美的な考慮によって正当化されている場合は、たとえば新しいコードを入力するときに名前空間を徐々に使用する可能性を検討する価値があることに注意してくださいこの新しいコードで。