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

設(shè)計模式是關(guān)於常見問題的常見解決方案。

……它們是概念，而不是藍圖；想法，未完成設(shè)計。
…他們?yōu)樵纠щy的情況增添了清晰度。

- Brandon Savage，PHP中的實用設(shè)計模式

鑰匙要點

Brandon Savage的“ PHP中實用設(shè)計模式”

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

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

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

---

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

>

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

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

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

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

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

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

>

忽略了??模型

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

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

>

“

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

知識的詛咒

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

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

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

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

wikipedia將其定義為：

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

>

自我出版

的瘟疫

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

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

結(jié)論

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

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

實際上，如果您是高級初學(xué)者（初學(xué)者應(yīng)該從非?；A(chǔ)的開始），但我仍然對您感興趣，我會為您提供鼓掌，並提供以下資源以在您深入研究之前進行查看：

>

在可學(xué)習(xí)的

上，面向?qū)ο蟮膒hp元素

>

>面向?qū)ο蟮膒hp

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

php

>中有關(guān)實用設(shè)計模式的經(jīng)常詢問的問題

>在PHP中使用設(shè)計模式的好處是什麼好處？他們提供了提高代碼效率和可維護性的方法。通過使用設(shè)計模式，您可以使代碼更加靈活，可重複使用和可理解。它們還使開發(fā)人員之間的溝通變得更加容易，因為它們?yōu)槟承┙鉀Q方案提供了標準術(shù)語。

>裝飾器模式如何在php？

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

>

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

>設(shè)計模式僅適用於PHP？

不，設(shè)計模式不是PHP獨有的。它們是軟件設(shè)計中的概念，可應(yīng)用於任何面向?qū)ο蟮木幊陶Z言。該實現(xiàn)可能因語言而異，但是基本原則保持不變。

>

設(shè)計模式如何改善開發(fā)人員之間的溝通？

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

>

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

>我如何開始在PHP項目中實現(xiàn)設(shè)計模式？

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

以上是圖書評論：PHP中的實用設(shè)計模式的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！