書評：PHPの実用的な設計パターン

PHPにおけるブランドンサベージの実用的なデザインパターンのこのレビューには、本と自己出版の側面の両方に関する私自身の意見と印象が含まれます。レビューコピーを教えてくれたブランドンに感謝します。

設計パターンは、一般的な問題に対する一般的な解決策に関するものです。
…それらは概念であり、青写真ではありません。アイデア、完成したデザインではありません。
…そうでなければ困難な状況に明確さを加えます。
- ブランドンサベージ、PHP

キーテイクアウト

ブランドン・サベージによる「PHPの実用的な設計パターン」は、一般的な問題の一般的な解決策に焦点を当てたPHPのデザインパターンを理解し、実装するための包括的なガイドを提供します。この本は幅広いパターンをカバーしており、それぞれが潜在的なコード実装で説明されているため、中級レベルの開発者にとって貴重なリソースになります。

本の内容が賞賛されている間、レビューではい​​くつかの欠点が指摘しています。これらには、レジストリパターンなどの特定のパターンの説明の欠如、および読者が高度な概念やサードパーティのコンテンツに精通しているという仮定が含まれます。また、このレビューでは、MVCアプリケーションにおけるモデルに対する本のアプローチと、ドメインモデルパターンの実用的な例がないことも批判しています。

このレビューは、コードサンプルの専門的なガイダンス、言語エラー、時折の奇妙さの欠如に見られるように、自己出版の課題を強調しています。これらの問題にもかかわらず、この本は、基本的な概念を最初に習得する必要がある初心者にはそうではありませんが、デザインパターンを掘り下げようとする中級開発者にはお勧めします。
コンテンツ
より軽い、紹介的なメモから始めて、ブランドンはフレームワークの必要性を説明し、OOPがクラスで物を包むことを意味するのではなく、デザインパターンを学ぶのが難しいように見える理由について詳しく説明すると主張します。その後、彼は堅実な原則への穏やかな紹介を続け、より高度な概念のための基礎を築きます。彼は、それぞれの堅実なルールが重要である理由とそれが何を意味するのかを説明しています。 Solidは十分に確立されたソフトウェア設計の原則であることを考えると、本で説明されようとしているすべてのパターンと比較するのは自然なことです。または、より正確に言うと、各パターンが堅実な原則をどれだけうまく尊重しているかを評価しながら、開発者に意図した機能を提供します。

ドレイファスモデルの用語で問題を表現した場合、彼は本が、実際に学習へのそのようなアプローチが完全に可能ではない場合、高度な初心者の間違いにさらさずに初心者を有能なレベルの開発者に変えるためにそこにあると主張します。人間の知識習得プロセスがどのように機能するかではありません

---

TOCからはあまり明白ではないかもしれないので、この本で説明されているパターンは次のとおりです。

（要約）工場パターン

• シングルトンパターン
• ビルダーパターン
• デコレーターパターン
• アダプターパターン
• ブリッジパターン
• ファサードパターン
• 戦略パターン
• メディエーターパターン
• オブザーバーパターン
• 責任のパターンの連鎖
• イテレーターパターン
• 複合パターン
• MVCパターン
• ドメインモデルパターン
• アクティブなレコードパターン
• フロントコントローラーパターン
• 非常に多くのパターンがカバーされている（そして最もよく覆われた）
>たとえば、レジ​​ストリパターン（この本ではカバーされていない）…

」などの文を見て驚いた。なぜだめですか？レジストリパターンは人気のあるパターンであり、最近では正確に推奨されていなくても説明するのは非常に簡単です。 パターンごとに

パターン、それぞれがよく説明され、ほとんどの場合、潜在的な実装を示すコード例が続きますが、キャッシュの工場パターンの例を不満があります。 パターンは、さまざまなキャッシュ（APCとMemcache）の例で実現され、両方とも工場を介して生成され、キャッシュコンポーネントが必要なサービスに注入されます。

それは私には理にかなっていますが、なぜ実際に工場のステップを必要とするのかと疑問に思う経験の少ない人々を見ることができます。また、単にコンストラクターにキャッシュインターフェイス自体をヒントするのではなく、キャッシュオブジェクト自体を注入する必要があります。工場ではありません。現在の例は、工場インターフェイスとキャッシュインターフェイスの両方を備えており、少なくとも、1つは余剰のようです。これは、中間レベルの開発者が親しみやすい方法で説明されることはありませんでした。また、ブリッジパターンの説明にも満足していません。表面に傷がついただけで、適切に戻らないように、欠けているように見えました。 一方、私は複合パターンの説明と非常に興味深いツリーの例に関するデモンストレーションを絶対に愛していました。著者は、メニュー構造、階層表現などに幻想的に適用される任意の数のネストノードレベルを持つ複合ツリーを構築します。 - そして、私は特にデコレーターのパターンの説明に興奮していました。それは非常に親しみやすい方法で、そして良い、使いやすい例で行われました。特にこのパターンは、私が常に尋ねられたときに突然人々に説明するのに苦労していたものであり、私はこの本よりもまだより良い故障を見つけていません。モデルの無視

本のある例では、ブランドンは、モデルはすべてのビジネスロジックと検証コードを含むMVCアプリケーションの最も重いリフターであると言います。これは、私が受け入れるにはあまりにも絶対的すぎる声明です。頭の上部から、これが真実ではない例を考えることができます：laravel。 Laravel 5が出てフォームリクエストを追加すると、モデルはさらに軽くなります。

認められて、一部の人々はすべてをモデルに入れる傾向がありますが、同じ量の神コードをコントローラーに入れた人もいます。私の経験と好みは、フレームワーク関連のすべてが非常に軽い（小さなコントローラー、小型モデル、小規模またはビューなし）、すべてのサービス関連（サービス、プラグイン、ライブラリ、ヘルパー）が必要なだけ太っている可能性があると言います。 、フレームワーク間で操作できる限り。それは個人的な好みだと思います。しかし、もう一つのことは私を奇妙に感じました：

「

優れたモデルの作成は、開発者がタックルする最も複雑なタスクの1つです。 長い間、Zend Frameworkのドキュメントは、モデルを作成することがアプリケーション開発プロセスの大部分であるため、Zend_Modelクラスはないと判断しました。 zend_modelを作成することは、誰もが同じモデル構造を使用できるか、使用したいと思うかを想定することです。これは、この章にコードを含めていないのと同じ理由で不可能です。 これは理にかなっていますが、最も単純なマナーで値、ゲートウェイ、ストレージオブジェクトを例示することは、初めてドメインモデルパターンに紹介される人々にとって非常に有益でした。私の意見では、ドメインモデルのパターンは、この本ではあまりにも無視されており、あまりにも理論的でした。

知識の呪い

本を通して、ブランドンは、読者がすべてに精通していると仮定して、それにリンクせずに、高度な概念（ORM、継承、依存関係注入）およびサードパーティのコンテンツに言及しています。特に4人のギャングは何度か言及されており、少なくともデザインパターンへのリンクを使用できます。そうでない場合は、「初心者」と「上級初心者」の読者は、混乱の中で文を一目見ます。

他の場合には、段落構造は、初心者から中級ユーザーの理解レベルをはるかに超えて書かれています。

それは古い質問です多くの開発者は常に苦労しています。依存関係を反転させ、クラス内にオブジェクトを作成しないように取り組んでいる場合、実行時間中に必要な依存関係を作成するにはどうすればよいですか'必然的に注入されますか？

これは、この本がパターンに慣れるために必要な読者が消耗するレベルではありません。この文を完全に理解している読者は、本のすべてのパターンにすでに完全に精通している可能性が高いため、実際のターゲットオーディエンスに疑問を投げかけています。これは、「知識の呪い」として知られているものに苦しんでいるサベージ氏によるものだと思います。

ウィキペディアはそれをそのように定義しています：

知識の呪いは、情報に基づいた政党の観点から問題について考えることが非常に難しいと判断するために、より詳細な知識のあるパーティーを導く認知的バイアスです。

知識の呪いは、彼らが知っていることを渡すように正式に訓練されていないが、時間、経験、フィードバックとともに効果を失うものでもある専門家の非常に一般的な出来事です。これが、私たちがSetePointで私たちの投稿について正直なフィードバックを提供するように奨励する理由であり、新しい出版物ごとに物事をよりシンプルで合理化しようとする理由です。誰も呪いに免疫がありません - 一部はそれによってより影響を受けます。

自己出版の疫病

近年、自己出版は本当に離陸したようです。 Brandonがこの本で行ったように、Leanpubに頼らない人は完全にソロになります。このアプローチは確かにプロセスをスピードアップし、専門家が驚くほど急速なペースで興味のあるパーティーの手に質の高いコンテンツを入れることができますが、より多くの間違い、悪いコンテンツ、タイプミスをすり抜けることもできます。

他の自己出版作家を悩ませている問題のほとんども、残念ながら、この本を悩ませています。経験豊富な編集者がいないため、コンテンツ、形式、または文法的および構文的な精度に関するガイダンスはなかったようです。

ネイティブスピーカーは間違いを犯さず、したがって正式な編集を必要としないと考えています。たとえば、Yベースの会社は、国Xの誰かを雇うためにX言語バージョンのサイトを校正しています。校正者が言語Xのネイティブスピーカーであることの唯一の根拠。それは私の母国語であるにもかかわらず、あなたのクロアチア語のウェブサイトの校正を校正するために私を雇いたくありませんが、あなたはより良い英語を見つけるのは難しいでしょう言語編集者。

結論

上級ユーザーとして、私は本で説明されているすべてのパターンではないにしても、ほとんどのほとんどの知識を持っていました。しかし、私が経験した説明は、私の意見では、より低いスキルの1つではありませんが、中間ユーザーにとってはよく形成され、親しみやすいものでした。この本の内容は非常に優れており、ブランドンは理論が説明していることをコードで示すのに優れていますが、私はこの本全体が初心者の開発者が具体的なものを何でも得るにはあまりにも複雑すぎると感じています。

PHPコミュニティ全般は、私には絶対的な初心者の本がある「ミッシングリンク」症候群のようなものに苦しんでいるようです（「これはエコーです、これは機能です、これはPHPタグです」）そして、このような中間の本、またはスタージョン、ジョーンズ、ハルジェスなどが出したものはありますが、質の高いコンテンツを欠いたままで、古き良き「古き良き」を介して征服できる中間地があります。火」アプローチ。

あなたがあなたの周りに立っている人々がそれらについて話しているが、あなたが何かを理解していない会議で、あなたがパターンに入り、それらの厄介なうなずきからパターンに入ろうとしている中間開発者であるならば、それは言った。あなたが初心者なら、私はあなたがこれを購入することをお勧めすることはできません - まだではありません。最初に「echos」をマスターし、作曲家が何であるかを学び、次に歯をこれに沈めてください。

実際には、あなたが上級初心者である場合（初心者は非常に基本的に始めるべきです）、それでもパターンに興味がある場合、私はあなたに称賛し、この本に飛び込む前に次のリソースを提供します：

>

学習可能なオブジェクト指向PHPの要素

オブジェクト指向php
オブジェクト指向PHP適用：2つの軍隊を互いに戦わせる
• アレハンドロ・ゲルヴァシオによる素晴らしさ - この男がこれまでに書いたすべてを読んでください
• 作曲家
• mvc
• 内容
私は本に4/5を与えますが、ラッシュの仕事を考慮すると、終わり近くにあったように見えます。私がすでに修正で汚染していたGithubリポジトリと専門的なガイダンスの明らかな欠如と、私が個人的にこの本につまずく初心者に間違った価値を埋め込むと信じているいくつかの奇妙さ（さまざまなコードの数字でクラス名を開始するサンプル）、私は3/5で最終スコアを終了しています。

php

の実用的な設計パターンに関するよくある質問

PHPで設計パターンを使用することの利点は何ですか？

PHPのデザインパターンは、ソフトウェア設計で一般的に発生する問題に対する再利用可能なソリューションを提供します。彼らはあなたのコードの効率と保守性を改善する方法を提供します。デザインパターンを使用することにより、コードをより柔軟で再利用可能、理解しやすくすることができます。また、特定のソリューションに標準の用語を提供するため、開発者間の通信を容易にします。これらのオブジェクトを特別なラッパーオブジェクトに配置することにより、オブジェクトに新しい動作を動的に追加します。 PHPでは、これは元のクラスをラップして追加の機能を提供するデコレータークラスを作成することで実現できます。デコレータークラスは、元のクラスと同じインターフェイスを実装し、そのインスタンスを保持します。デコレータへのすべての呼び出しは元のクラスに転送され、追加の動作が追加されます。

設計システム、パターンライブラリ、スタイルガイドの違いは何ですか？パターンライブラリとスタイルガイドはすべて、設計と開発の一貫性を維持するのに役立つツールです。設計システムとは、設計と開発プロセスを管理する哲学、原則、ツールを含む包括的な構造です。パターンライブラリは、設計システムのサブセットであり、再利用可能な設計要素とコンポーネントが含まれています。一方、スタイルガイドは、色、タイポグラフィ、間隔などの視覚的なデザイン要素の概要を説明するドキュメントです。パターンライブラリは、設計の一貫性を実現する上で重要なツールです。プロジェクトのさまざまな部分で使用できる一連の再利用可能なコンポーネントを提供します。これらの事前定義されたコンポーネントを使用することにより、同じ設計パターンが一貫して使用され、よりまとまりのあるユーザーフレンドリーなデザインにつながることを確認してください。リファクタリングは、既存のコードを変更して、機能を変更せずに構造を改善するプロセスです。設計パターンのコンテキストでは、リファクタリングを使用して、既存のコードベースに設計パターンを実装できます。これにより、コードの保守性、読みやすさ、そして多くの場合パフォーマンスが向上します。

本「PHPの実用的なデザインパターン」は、デザインパターンの理解にどのように役立ちますか？ 」は、PHPの設計パターンを理解および実装するための包括的なガイドを提供します。さまざまなデザインパターンの実用的な例と詳細な説明を提供するため、読者が概念を把握し、自分のプロジェクトに適用しやすくなります。

設計パターンはPHPにのみ適用されますか？

いいえ、設計パターンはPHP専用ではありません。これらは、オブジェクト指向のプログラミング言語に適用できるソフトウェア設計のコンセプトです。実装は言語ごとに異なる場合がありますが、根本的な原則は同じままです。

デザインパターンが開発者間のコミュニケーションを改善するにはどうすればよいですか？ 。開発者がこれらの用語を使用する場合、誤解を減らし、コミュニケーションを改善する特定の、よく理解されている概念を伝えます。

デザインパターンを使用することに欠点はありますか？ 、適切に使用しないと複雑さを導入することもできます。デザインパターンの過剰使用は、不必要な抽象化につながる可能性があり、コードの理解と維持をより困難にすることができます。したがって、それらを慎重に使用し、繰り返しの問題を真に解決した場合にのみそれらを使用することが重要です。 PHPプロジェクトは、解決しようとしている問題を理解し、設計パターンが解決できる繰り返しの問題であるかどうかを特定することです。適切なデザインパターンを特定したら、コードに実装を開始できます。目標は、コードをより効率的かつ保守可能にすることであるため、常にシンプルさと明確さを念頭に置いてください。

以上が書評：PHPの実用的な設計パターンの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。