圖書評論：PHP中的實用設計模式

對Brandon Savage在PHP中的實用設計模式的評論將包括我對書籍的看法和印象，以及自我出版的方面。非常感謝Brandon給了我評論副本。

設計模式是關於常見問題的常見解決方案。

……它們是概念，而不是藍圖；想法，未完成設計。
…他們為原本困難的情況增添了清晰度。

- Brandon Savage，PHP中的實用設計模式

鑰匙要點

Brandon Savage的“ PHP中實用設計模式”

為理解和實施PHP中的設計模式提供了綜合指南，重點是針對常見問題的共同解決方案。該書涵蓋了廣泛的模式，每個模式都用潛在的代碼實現進行了解釋，這使其成為中級開發人員的寶貴資源。
• >
>對本書的內容受到讚揚，評論指出了一些缺點。其中包括缺乏對某些模式的解釋，例如註冊表模式，以及讀者熟悉高級概念和第三方內容的假設。該評論還批評了本書在MVC應用程序中的模型方法，並且缺乏針對域模型模式的實際示例。
• >評論重點介紹了本書缺乏專業指導，語言錯誤和偶爾在代碼樣本中的奇數的挑戰。儘管存在這些問題，但建議該書適用於希望研究設計模式的中級開發人員，但對於需要首先掌握基本概念的初學者。
• content

從更輕的介紹性註釋開始，布蘭登解釋了對框架的需求，認為OOP並不意味著要在課堂上包裝一些東西，並詳細介紹了為什麼設計模式似乎很難學習。然後，他繼續對紮實的原則進行溫和的介紹，並為更高級的概念奠定了基礎。他解釋了為什麼每個堅實的規則都很重要，這意味著什麼。鑑於Solid是一個良好的軟件設計原則，因此將其與本書中要解釋的每種模式進行比較是很自然的。或者，更確切地說，要評估每種模式如何尊重堅實的原則，同時為開發人員提供其預期的功能。

>如果我在Dreyfus模型術語中表達了重要的事情，他聲稱這本書將在那裡將新手變成一個勝任的級別的開發人員，而不會使他們遭受高級初學者的錯誤，而實際上，這種學習方法並非完全可能- 那是可能的- 只是人類知識獲取過程的工作原理。

---

>從TOC中可能不會過分明顯，因此本書中解釋的模式是：

>

• （摘要）工廠模式
• singleton模式
• 構建器模式
• 裝飾器圖案
• 適配器模式
橋模式
外觀模式
策略模式
介質模式
觀察者模式
責任鏈模式
迭代器模式
複合模式
MVC模式
域模型模式
活動記錄模式
前控制器模式

>涵蓋瞭如此多的模式（並且最涵蓋的效果最多），我驚訝地看到一個句子，例如“

[…]，例如，註冊表模式（本書中未涵蓋）…”。為什麼不呢？註冊表模式是一種流行的模式，即使不是當今不完全推薦的，也很容易解釋。 > 按模式進行模式，每個圖案都很好地解釋了，大多數隨後是代碼示例，證明了它們的潛在實現，儘管我確實對Cache的出廠模式示例有一個困惑。

在不同的緩存示例（APC和memcache）的示例中實現了該模式，並且兩者都通過工廠產生，該工廠都注入了任何服務需要緩存組件中。 >

>對我來說很有意義，但是我看到經驗不足的人想知道為什麼一個人可能真的需要工廠步驟，而不僅僅是鍵入提示構造函數中的緩存界面本身，需要注入緩存對象本身，而不是其工廠。當前示例既具有出廠接口和高速緩存接口，至少，一個似乎是剩餘的。這從來沒有以中級開發人員平易近人的方式來解釋，我擔心它可能會使某些人感到困惑。我對橋樑模式的解釋也不滿意 - 它似乎缺乏，就像它只是在表面上被劃傷了，從來沒有正確返回一樣。

> 另一方面，我絕對喜歡複合模式的解釋及其在非常有趣的樹示例上的演示- 作者構建了一棵複合樹，具有任意數量的嵌套節點級別，該級別非常適用於菜單構建，層次結構，以及更多- 我對裝飾圖案的解釋感到特別興奮。它是以一種非常平易近人的方式完成的，並且以良好的可用示例進行。尤其是這種模式是我一直很難在被問到時用藍色解釋的人，而且我還沒有找到比本書更好的細分。

>

忽略了​​模型

在本書的一個實例中，布蘭登說，模型是MVC應用程序中最重的舉昇機，其中包含所有業務邏輯和驗證代碼。這是我無法接受的陳述 - 我可以想到一個不正確的例子：拉拉維爾（Laravel）。隨著Laravel 5的出現並添加表格請求，這些模型將增長更輕。

被授予，有些人傾向於將所有東西都放在模型中，但是有些人也將相同數量的上帝代碼放入控制器中。我的經驗和偏好說，與框架相關的一切都應該很輕（小型控制器，小型模型，小或沒有視圖），而與服務有關的一切（服務，插件，圖書館，助手）都可以像他們需要一樣胖，只要它們之間可以在框架之間進行可行的操作。我想那是個人的喜好。另一件事讓我感到奇怪：

>

“

創建好的模型是任何開發人員鏟球最複雜的任務之一。 長期以來，Zend Framework文檔認為沒有Zend_model類，因為創建模型是應用程序開發過程的大部分。 要創建zend_model將是假設每個人都可以或想使用相同的模型結構，這是不可能的，這是我本章中未包含任何代碼的相同原因。 >這確實有意義，但以最簡單的方式體現了價值，網關和存儲對象，這對首次被引入域模型模式的人們非常有益。我認為，在本書中，域模型模式過於忽視，並且太過理論上了。

知識的詛咒

在整本書中，布蘭登在沒有鏈接到它的情況下（四個幫派）提到了高級概念（ORM，繼承，依賴注入）和第三方內容，假設讀者熟悉這一切。尤其是四個場合提到了四個團伙，並且至少可以與設計模式的鏈接使用 - 否則“新手”和“高級初學者”讀者只會在混亂中瀏覽一下句子。

在其他情況下，段落結構的編寫方式遠遠超出了新手對中級用戶的理解水平：

>這是一個古老的問題，許多開發人員一直都在努力：如果我努力顛倒依賴關係而不是在課堂內創建對象，那麼我該如何創建在運行時需要的依賴項，可以一定要注入？

>這不是讀者所消耗的水平，他們需要這本書熟悉模式。完全了解這句話的讀者可能已經完全熟悉了書中的所有模式，從而使真正的目標受眾質疑。我相信這是由於薩維奇先生遭受了所謂的“知識詛咒”的困擾。

wikipedia將其定義為：

知識的詛咒是一種認知偏見，它導致更有信息的各方發現從較小的政黨的角度考慮問題非常困難。 在沒有正式訓練以傳達自己所知道的東西的專業人士中，知識的詛咒是一個非常普遍的事情，但也確實會隨著時間，經驗和反饋而失去影響。這也是為什麼我們在站點點鼓勵人們就帖子提供誠實的反饋，這就是為什麼我們試圖使每個新出版物都更簡單，更簡化的事情。沒有人對詛咒免疫 - 有些人受到它的影響更大。

>

自我出版

的瘟疫

>近年來，自我出版似乎確實脫穎而出。那些不訴諸LeanPub的人像Brandon一樣完全獨奏。儘管這種方法確實確實加快了過程，並允許專家以令人震驚的快速速度將高質量的內容放在感興趣的各方的手中，但它還允許更多的錯誤，不良內容和錯別字可以通過。 不幸的是，困擾其他自我出版作家的大多數問題也困擾著這本書。缺乏經驗豐富的編輯，似乎沒有關於內容，形式甚至語法和句法準確性的指導，這是一種經常弄亂的語言的人。

>以為母語者不會犯錯誤，因此不需要正式編輯類似於例如，一家基於Y校對者的唯一理由是語言X的母語。語言編輯。

結論

作為高級用戶，我以前對本書中解釋的大多數（如果不是全部）的模式有所了解。但是，我所經歷的解釋對中級用戶的形成且平易近人，儘管我認為不是較低的技能之一。雖然這本書的內容非常好，而布蘭登（Brandon）非常擅長在代碼中展示該理論的描述，但我覺得這本書整體上太複雜了，對於新手開發人員而言，無法獲得任何明顯的內容。 在我看來，PHP社區一般都患有一種“缺少鏈接”綜合徵，我們擁有絕對的初學者書籍（“這是迴聲，這是一個函數，這是PHP標籤”））））還有像這樣的中級書籍，或任何st魚，瓊斯，哈特耶斯和其他人都推出的，但是有一個中間立場仍然沒有質量的內容，只能通過良好的老式征服“把我扔進去火法。

>也就是說，如果您是一個中級開發人員，希望在人們周圍的人們談論他們談論的會議上陷入模式，並從那些尷尬的點點頭，但您不理解一件事情- 一定會得到這本書。如果您是新手，我不建議您購買這個 - 不僅是。首先掌握您的“ Echos”，了解作曲家是什麼，然後將您的牙齒沉入此。

實際上，如果您是高級初學者（初學者應該從非常基礎的開始），但我仍然對您感興趣，我會為您提供鼓掌，並提供以下資源以在您深入研究之前進行查看：

>

在可學習的

上，面向對象的php元素

>

>面向對象的php

• 採用面向對象的PHP：使兩支軍隊互相戰鬥
> Alejandro Gervasio的
• >很棒 - 閱讀這個人曾經寫過的所有內容
作曲家
MVC
• 內容，我會給書一個4/5，但是考慮到急需的工作似乎已經接近結束，錯字和語言錯誤（儘管公平，但有一個錯別字提交我已經對修復程序進行了污染的github回購）以及我個人認為，很明顯缺乏專業指導以及一些奇怪的奇怪之處，這些奇怪的價值會嵌入到新手中的新手中（在各種代碼樣本中使用數字啟動班級名稱），i i' m結束最終分數為3/5。

php

>中有關實用設計模式的經常詢問的問題

>在PHP中使用設計模式的好處是什麼好處？他們提供了提高代碼效率和可維護性的方法。通過使用設計模式，您可以使代碼更加靈活，可重複使用和可理解。它們還使開發人員之間的溝通變得更加容易，因為它們為某些解決方案提供了標準術語。

>裝飾器模式如何在php？

中起作用？通過將這些對象放入特殊包裝器對像中，將新行為添加到對像中。在PHP中，可以通過創建包裝原始類並提供其他功能的裝飾符類來實現。 Decorator類實現與原始類相同的接口，並擁有一個實例。所有對裝飾器的呼叫都將轉發到原始類，然後添加了其他行為。圖案庫和样式指南都是有助於保持設計和開發一致性的工具。設計系統是總體結構，其中包括控制設計和開發過程的理念，原理和工具。模式庫是設計系統的子集，包括可重複使用的設計元素和組件。另一方面，樣式指南是一份文檔，概述了視覺設計元素，例如顏色，版式和間距。圖案庫是實現設計一致性的關鍵工具。它們提供了一組可重複使用的組件，可以在項目的不同部分中使用。通過使用這些預定義的組件，您可以確保一致使用相同的設計模式，從而導致更具凝聚力和用戶友好的設計。

>

>重構在設計模式中的作用是什麼？重構是修改現有代碼以改善其結構而無需更改其功能的過程。在設計模式的背景下，可以使用重構將設計模式實現到現有代碼庫中。這可以提高代碼的可維護性，可讀性和經常性能。
>“ PHP中的實用設計模式”如何幫助理解設計模式？ ”提供了PHP中理解和實施設計模式的綜合指南。它提供了各種設計模式的實踐示例和詳細說明，使讀者更容易掌握這些概念並將其應用於自己的項目中。

>設計模式僅適用於PHP？

不，設計模式不是PHP獨有的。它們是軟件設計中的概念，可應用於任何面向對象的編程語言。該實現可能因語言而異，但是基本原則保持不變。

>

設計模式如何改善開發人員之間的溝通？

設計模式為軟件設計中的某些解決方案提供了標準術語。當開發人員使用這些術語時，他們傳達了一個特定的，充分理解的概念，可以減少誤解並改善溝通。

>

>使用設計模式有任何缺點嗎？ ，如果不正確使用，它們也可以引入複雜性。過度使用設計模式可能會導致不必要的抽象，並使代碼更難理解和維護。因此，只有在他們真正解決一個反復出現的問題時，才明智地使用它們。

>我如何開始在PHP項目中實現設計模式？

>您的PHP項目是了解您要解決的問題，並確定這是否是設計模式可以解決的重複問題。確定了合適的設計模式後，您可以在代碼中開始實現它。請記住，目標是使您的代碼更有效和可維護，因此請始終牢記簡單性和清晰度。

以上是圖書評論：PHP中的實用設計模式的詳細內容。更多資訊請關注PHP中文網其他相關文章！