PHP依存関係逆転ケースの詳細説明

今回は、PHPの依存関係逆転の場合について詳しく説明します。PHPの依存関係逆転の注意点は何ですか?実際のケースを見てみましょう。

依存関係の逆転とは何ですか?簡単に言うと、依存関係を依存関係インターフェイスに反転するということです。具体的な概念は次のとおりです:

1. 上位モジュールはすべて抽象化 (親) に依存すべきではありません。クラスはサブクラスに依存できません。すべてがサブクラスに依存します) (抽象クラスの場合)

2. 抽象化は具体性に依存することはできず、具体性は抽象化に依存する必要があります。

ここでいうインターフェース

は、狭義のインターフェースではないことに注意してください。

なぜインターフェースに依存するのでしょうか?インターフェイスは問題の抽象化を具体化しており、抽象化は一般に比較的安定しているか、比較的頻繁に変更されないため、具象は変更可能です。したがって、依存関係の抽象化は、コード拡張とランタイム バインディング (ポリモーフィズム) を実装するための基礎となります。抽象クラスのサブクラスが実装されている限り、そのクラスのすべてのユーザーがそれを使用できます。ここでは、スケーラビリティの概念が強調されます。通常、拡張性とは既知の動作の拡張を指しますが、インターフェイスについて話すときは、インターフェイスが相対的である必要があるとも言われます。これは、どんなに高度な

設計パターン を使用しても、コードを変更せずに刻々と変化する状況を実現することは不可能であることを示しています。オブジェクト指向の 5 つの原則の中で、依存関係の逆転は理解と実装が最も難しいと思います。

ここでは従業員クラスを例に挙げます

<?php
interface employee
{
  public function working();
}
class teacher implements employee
{
  public function working()
  {
    echo &#39;teaching...&#39;;
  }
}
class coder implements employee
{
  public function working()
  {
    echo &#39;coding...&#39;;
  }
}
class workA
{
  public function work()
  {
    $teacher = new teacher();
    $teacher->working();
  }
}
class workB
{
  private $e;
  public function set(employee $e)
  {
    $this->e = $e;
  }
  public function work()
  {
    $this->e->working();
  }
}
$worka = new workA;
$worka->work();
$workb = new workB;
$workb->set(new teacher());
$workb->work();

workA では、work メソッドは教師の実装に依存しますが、workB では、work は代わりに抽象化に依存するため、必要なオブジェクトをパラメータを通じて渡すことができます。上記のコードはインターフェイスを通じてある程度の分離を実現しますが、それでも限界があります。インターフェイスを使用するだけでなく、ファクトリを使用しても、ある程度の分離と依存関係の逆転を実現できます。

workBでは、setメソッドを通じて教師インスタンスが渡され、

ファクトリーパターンが実現されます。このような実装はまだハードコーディングされているため、コードをさらに拡張するには、この依存関係を設定ファイルに書き込み、workB がプログラムによって特別に設定された教師オブジェクト (依存オブジェクトなど) を必要とすることを示します。クラス ファイル) が存在します)、およびロード設定で依存する実装は、IOC コンテナーと呼ばれます。

IOC (Inversion of Control) の概念は多くの記事で見られますが、実際、IOC は依存性反転原則 (DIP) の同義語です。 IOC について言及するときに、DI などの概念について言及する人もいるかもしれません。 DI、つまり

依存性注入 は、依存性注入 (DI) と依存性ルックアップ (DS) の 2 つの実装が IOC であると一般に考えられています。しかし、いくつかの一般的な概念の進化に伴い、これらの概念間の関係があいまいになり、IOC が DI であると考える人もいます。 IOC よりも依存性注入の説明の方が適切であると考える人もいますが、これらの概念間の関係はここでは複雑になりません。

古典的な J2EE 設計では、DAO 層と Servicen 層は通常、インターフェイス層と実装層に分割され、依存関係が構成ファイルで構成されます。これは最も一般的な DIP アプリケーションです。 Spring フレームワークは、コードから IOC ウィンドウへの制御を分離する優れた IOC コンテナです。これは、Spring が実行中に構成ファイルの設定に従ってオブジェクト間の依存関係を確立します。

以下のコードに示すように

<bean scopre="prototype" class="cn.notebook.action.NotebookListOtherAction" id="notebookListOtherAction">
  <property ref="userReplyService" name="userReplyService" />
  <property ref="userService" name="userService" />
  <property ref="permissionService" name="permissionService" />
  <property ref="friendService" name="friendService" />
</bean>

ただし、このような設定には依然として問題があり、設定ファイルはますます大きくなり、それらの関係はますます複雑になります。また、アプリケーションやビジネスの変化に応じて常にコードを変更するという悪夢から逃れることはできません (ここでは、構成ファイルはコードの一部とみなされます。また、実際の開発では、構成ファイルを単純に変更することはほとんどありません。一般に、設定ファイルが変更されると、コードもそれに応じて変更されます)

PHP には Spring を模倣した実装もあります。つまり、依存関係が設定ファイルに記述され、必要なオブジェクトが設定ファイルを通じて生成されます。このようなコードは実装のためにまだ実装されていると思います。 Srping では、構成ファイルはクラスの実行時の依存関係だけでなく、トランザクション管理、AOP、遅延読み込みなども構成します。 PHP で上記の機能を実現するには、消費量が膨大になります。言語の観点から見ると、PHP のような動的スクリプト言語は、いくつかの多態性機能の実装においてコンパイル言語とは異なります。第二に、PHP はアジャイル開発言語として、迅速な開発、明確なロジック、およびよりシンプルで理解しやすいコードを重視します。さまざまなデザイン パターン フレームワークを追加することは、技術的な実装と運用効率の観点からお勧めできません。依存関係の逆転の中心原理は分離です。この最も原始的な原則から逸脱することは、本末転倒です。

実際、依存関係の反転の原則はすでに多くの設計パターンに暗黙的に組み込まれており、意図的または非意図的にいくつかの依存関係の反転作業も行っています。ただ、PHP としては、現時点では比較的完全な IOC コンテナが存在せず、おそらく PHP にはそれがまったく必要ないのかもしれません。

DIP が満たされている場合:

1. 各上位レベルのクラスは、必要なサービスのインターフェイス宣言を提案し、下位レベルのクラスはこのインターフェイスを実装します。

2. 各高レベルのクラスは、この抽象インターフェイスを通じてサービスを使用します。

この記事の事例を読んだ後は、この方法を習得したと思います。さらに興味深い情報については、php 中国語 Web サイトの他の関連記事に注目してください。

推奨読書:

Bootstrap+PHP 複数の画像アップロードを実装する手順の詳細な説明

CIフレームワークのショッピングカート機能を実装する詳細な手順

以上がPHP依存関係逆転ケースの詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。