コアポイント
各固体原理の関連性についてarbitrary意的な「ソロモン」の決定を下す場合、逆転（DIP）への依存の原則が最も過小評価されていると思います。オブジェクト指向設計の分野のコア概念のいくつかは、懸念の分離やスイッチングの実装など、最初は理解するのが困難ですが、一方、インターフェイス指向のプログラミングなど、より直感的でより明確なパラダイムはより単純です。残念ながら、DIPの正式な定義は両刃の剣のような呪い/祝福に包まれています。多くの場合、人々は前述の「インターフェイス指向のプログラミング」という戒めの別の声明としての原則にデフォルトになるため、プログラマーはそれを無視します。
一見すると、上記の声明は自明のようです。現在、具体的な実装に強い依存に基づいて構築されたシステムが悪いデザインの悪い前兆であることに同意しないことを考えると、いくつかの抽象化を切り替えることは完全に合理的です。したがって、これにより、DIPの主な焦点はインターフェイス指向のプログラミングに関するものだと考えて、出発点に戻ります。実際、この原則の要件を満たす場合、実装からのインターフェイスをデカップリングすることは、半仕上げの方法にすぎません。不足している部分は、実際の反転プロセスを実装することです。もちろん、疑問が生じます：反転とは何ですか？従来、システムは常に高レベルのコンポーネント（クラスであろうとプロセスルーチンであろうと）を低レベルコンポーネントに依存するように設計されています（詳細）。たとえば、ロギングモジュールは、一連の特定のロガー（実際に情報をシステムに記録する）に強い依存関係を持っている場合があります。したがって、ロガーのプロトコルが変更されるたびに、このスキームは、プロトコルが抽象化されていても、上層層への副作用が騒々しくなります。ただし、DIPの実装は、ロギングモジュールにプロトコルを持たせることにより、これらのリップルをある程度緩和するのに役立ち、全体的な依存関係を反転させます。反転後、ロガーはプロトコルを忠実に順守する必要があるため、将来の変更がある場合は、それに応じて変更し、プロトコルの変動に適応する必要があります。要するに、これは、標準的なインターフェイスのみに依存するよりも、DIPが舞台裏で少し複雑であることを示しています - デカップリングを実装しています。はい、それは抽象化に依存する高レベルのモジュールと低レベルの両方のモジュールを抽象化に依存するようにすることについて説明しますが、同時に高レベルのモジュールにはこれらの抽象化が必要です。ご想像のとおり、DIPが実際にカバーするものを理解するのに役立つ可能性のある1つの方法は、いくつかの実用的なコード例を使用しています。したがって、この記事では、PHPアプリケーションを開発する際にこの強固な原則を活用する方法を学ぶことができるように、いくつかの例を設定します。
単純なストレージモジュール（DIPで欠落している「I」）を開発します
多くの開発者、特にオブジェクト指向のPHPを嫌う開発者は、ディップやその他の堅実な原則を厳格なドグマと見なす傾向があり、言語に固有のプラグマティズムに対抗します。このアイデアは、原則の本当の利点を示す実用的なPHPの例を野生で見つけることが困難であるため、理解できます。私は啓発されたプログラマーとして自分自身を宣伝しようとはしていません（そのスーツはうまくいきません）が、良い目標のために一生懸命働き、実用的な観点から実際のユースケースにDIPを実装する方法を示すことは依然として役立ちます。まず、シンプルなファイルストレージモジュールの実装を検討します。このモジュールは、指定されたターゲットファイルからデータの読み取りと書き込みを担当します。非常に単純化されたレベルでは、質問のモジュールは次のように書くことができます：
<?php namespace LibraryEncoderStrategy;
class Serializer implements Serializable
{
protected $unserializeCallback;
public function __construct($unserializeCallback = false) {
$this->unserializeCallback = (boolean) $unserializeCallback;
}
public function getUnserializeCallback() {
return $this->unserializeCallback;
}
public function serialize($data) {
if (is_resource($data)) {
throw new InvalidArgumentException(
"PHP resources are not serializable.");
}
if (($data = serialize($data)) === false) {
throw new RuntimeException(
"Unable to serialize the supplied data.");
}
return $data;
}
public function unserialize($data) {
if (!is_string($data) || empty($data)) {
throw new InvalidArgumentException(
"The data to be decoded must be a non-empty string.");
}
if ($this->unserializeCallback) {
$callback = ini_get("unserialize_callback_func");
if (!function_exists($callback)) {
throw new BadFunctionCallException(
"The php.ini unserialize callback function is invalid.");
}
}
if (($data = @unserialize($data)) === false) {
throw new RuntimeException(
"Unable to unserialize the supplied data.");
}
return $data;
}
}<?php namespace LibraryFile;
class FileStorage
{
const DEFAULT_STORAGE_FILE = "default.dat";
protected $serializer;
protected $file;
public function __construct(Serializable $serializer, $file = self::DEFAULT_STORAGE_FILE) {
$this->serializer = $serializer;
$this->setFile($file);
}
public function getSerializer() {
return $this->serializer;
}
public function setFile($file) {
if (!is_file($file) || !is_readable($file)) {
throw new InvalidArgumentException(
"The supplied file is not readable or writable.");
}
$this->file = $file;
return $this;
}
public function getFile() {
return $this->file;
}
public function resetFile() {
$this->file = self::DEFAULT_STORAGE_FILE;
return $this;
}
public function write($data) {
try {
return file_put_contents($this->file,
$this->serializer->serialize($data));
}
catch (Exception $e) {
throw new Exception($e->getMessage());
}
}
public function read()
{
try {
return $this->serializer->unserialize(
@file_get_contents($this->file));
}
catch (Exception $e) {
throw new Exception($e->getMessage());
}
}
}このモジュールは、いくつかの基本的なコンポーネントのみで構成されるかなり単純な構造です。ファーストクラスはファイルシステムからデータを読み取り、書き込みます。2番目のクラスは、内部でデータの保存可能な表現を生成するための単純なPHPシリアナーです。これらのサンプルコンポーネントは、単独でビジネスをうまく機能させ、このように接続して同期して作業することができます。
<?php use LibraryLoaderAutoloader,
LibraryEncoderStrategySerializer,
LibraryFileFileStorage;
require_once __DIR__ . "/Library/Loader/Autoloader.php";
$autoloader = new Autoloader;
$autoloader->register();
$fileStorage = new FileStorage(new Serializer);
$fileStorage->write(new stdClass());
print_r($fileStorage->read());
$fileStorage->write(array("This", "is", "a", "sample", "array"));
print_r($fileStorage->read());
$fileStorage->write("This is a sample string.");
echo $fileStorage->read();プロトコルの所有権とデカップリングインターフェイスと実装（DIPの完全な使用の維持）
多くの選択肢はありませんが、プロトコルの抽象化を維持しながら、Filestorageクラスとその低レベルの共同作業者との間にプロトコルの所有権を効果的に逆転させる方法がまだあります。ただし、PHPネームスペースの自然なカプセル化に依存しているため、非常に直感的な方法があります。このややとらえどころのない概念を具体的なコードに変換するために、モジュールに最初に変更する必要があるのは、PHPシリアル化以外の形式で簡単に操作できるように、ファイルデータを保存および取得するための緩いプロトコルを定義することです。以下に示すように合理化された孤立したインターフェイスは、優雅に単純に仕事をすることができます：
<?php namespace LibraryEncoderStrategy;
class Serializer implements Serializable
{
protected $unserializeCallback;
public function __construct($unserializeCallback = false) {
$this->unserializeCallback = (boolean) $unserializeCallback;
}
public function getUnserializeCallback() {
return $this->unserializeCallback;
}
public function serialize($data) {
if (is_resource($data)) {
throw new InvalidArgumentException(
"PHP resources are not serializable.");
}
if (($data = serialize($data)) === false) {
throw new RuntimeException(
"Unable to serialize the supplied data.");
}
return $data;
}
public function unserialize($data) {
if (!is_string($data) || empty($data)) {
throw new InvalidArgumentException(
"The data to be decoded must be a non-empty string.");
}
if ($this->unserializeCallback) {
$callback = ini_get("unserialize_callback_func");
if (!function_exists($callback)) {
throw new BadFunctionCallException(
"The php.ini unserialize callback function is invalid.");
}
}
if (($data = @unserialize($data)) === false) {
throw new RuntimeException(
"Unable to unserialize the supplied data.");
}
return $data;
}
}encoderInterfaceの存在は、ファイルモジュールの全体的な設計に大きな影響を与えるわけではないようですが、表面的に約束されているもの以上のものがあります。最初の改善は、データをエンコードおよびデコードするための非常に一般的なプロトコルの定義です。 2番目の改善は、最初の改善と同じくらい重要です。つまり、プロトコルの所有権は、インターフェイスがクラスの名前空間に存在するため、Filestorageクラスに属します。要するに、正しい名前空間を持つインターフェイスを書くだけで、まだ定義されていない低レベルのエンコーダー/デコーダーが高レベルのFileStorageに依存するようにすることができました。要するに、これはアカデミックベールの背後にある擁護をする実際の逆転プロセスです。もちろん、Filestorageクラスが以前のインターフェイスを注入する実装者に変更されていない場合、反転は不器用な中間試みになります。
<?php namespace LibraryFile;
class FileStorage
{
const DEFAULT_STORAGE_FILE = "default.dat";
protected $serializer;
protected $file;
public function __construct(Serializable $serializer, $file = self::DEFAULT_STORAGE_FILE) {
$this->serializer = $serializer;
$this->setFile($file);
}
public function getSerializer() {
return $this->serializer;
}
public function setFile($file) {
if (!is_file($file) || !is_readable($file)) {
throw new InvalidArgumentException(
"The supplied file is not readable or writable.");
}
$this->file = $file;
return $this;
}
public function getFile() {
return $this->file;
}
public function resetFile() {
$this->file = self::DEFAULT_STORAGE_FILE;
return $this;
}
public function write($data) {
try {
return file_put_contents($this->file,
$this->serializer->serialize($data));
}
catch (Exception $e) {
throw new Exception($e->getMessage());
}
}
public function read()
{
try {
return $this->serializer->unserialize(
@file_get_contents($this->file));
}
catch (Exception $e) {
throw new Exception($e->getMessage());
}
}
}分析Serializerの背後にあるロジックは間違いなく冗長です。それにもかかわらず、今ではゆるいエンコード/デコードの抽象化に依存しているだけでなく、抽象化の所有権が名前空間レベルで明示的に公開されていることを指摘する価値があります。繰り返しますが、さらに一歩進んで、DIPの利点を強調するために、より多くのエンコーダーの書き込みを開始できます。そうは言っても、ここに記述すべきもう1つの追加の低レベルコンポーネントがあります：
<?php use LibraryLoaderAutoloader,
LibraryEncoderStrategySerializer,
LibraryFileFileStorage;
require_once __DIR__ . "/Library/Loader/Autoloader.php";
$autoloader = new Autoloader;
$autoloader->register();
$fileStorage = new FileStorage(new Serializer);
$fileStorage->write(new stdClass());
print_r($fileStorage->read());
$fileStorage->write(array("This", "is", "a", "sample", "array"));
print_r($fileStorage->read());
$fileStorage->write("This is a sample string.");
echo $fileStorage->read();予想どおり、余分なエンコーダの背後にある根本的なロジックは、顕著な改善とバリアントを除き、最初のPHPシリアイザーに似ていることがよくあります。さらに、これらのコンポーネントはDIP課題の要件に準拠しているため、Filestorage Namespaceで定義されているエンコード/デコードプロトコルに準拠しています。ファイルモジュールの上部レベルと下位レベルの両方のコンポーネントは抽象化に依存しており、エンコーダはファイルストレージクラスに明確な依存性を持っているため、モジュールがDIP仕様に沿って動作していると安全に主張できます。さらに、次の例は、これらのコンポーネントを組み合わせる方法を示しています。
<?php namespace LibraryFile;
interface EncoderInterface
{
public function encode($data);
public function decode($data);
}結論
<?php namespace LibraryFile;
class FileStorage
{
const DEFAULT_STORAGE_FILE = "default.dat";
protected $encoder;
protected $file;
public function __construct(EncoderInterface $encoder, $file = self::DEFAULT_STORAGE_FILE) {
$this->encoder = $encoder;
$this->setFile($file);
}
public function getEncoder() {
return $this->encoder;
}
public function setFile($file) {
if (!is_file($file) || !is_readable($file)) {
throw new InvalidArgumentException(
"The supplied file is not readable or writable.");
}
$this->file = $file;
return $this;
}
public function getFile() {
return $this->file;
}
public function resetFile() {
$this->file = self::DEFAULT_STORAGE_FILE;
return $this;
}
public function write($data) {
try {
return file_put_contents($this->file,
$this->encoder->encode($data));
}
catch (Exception $e) {
throw new Exception($e->getMessage());
}
}
public function read() {
try {
return $this->encoder->decode(
@file_get_contents($this->file));
}
catch (Exception $e) {
throw new Exception($e->getMessage());
}
}
}kentoh/shutterstockの写真
依存関係の反転原理に関するよくある質問
依存関係の反転原理（DIP）の主な目的は何ですか？従来のプログラマティックプログラミングとDIPはどう違うのですか？
DIPの実用的なアプリケーションの簡単な例を提供できますか？
私のコードでDIPを使用することの利点は何ですか？
DIPを実装することの欠点や課題は何ですか？
dipは堅実な略語の最後の原則ですが、他の原則と密接に関連しています。たとえば、単一の責任原則（SRP）とオープンおよびクローズ原理（OCP）の両方が、DIPの重要な側面であるデカップリングを促進します。リヒター置換原理（LSP）とインターフェイス分離原理（ISP）の両方が、DIPの中心にある抽象化を扱います。
コードにディップの適用を開始するにはどうすればよいですか？
DIPは私のコードのパフォーマンスを改善できますか？
DIPは、大規模で複雑なシステムにのみ便利ですか？
以上が依存関係の反転原理の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
