請人清除了我與這些模式在我腦海中的混亂：在什麼情況下，命令鏈設計模式適用？
我見過很多網站，其中兩個是相同的（與責任鏈相同的命令鏈的例子）以及其他不在的網站。
這是我瞭解每個：
CHAIN命令：
一類我們稱之爲CommandChain，以持有物業「命令」，這是類的實例的一個列表，它實現相同的界面。假設他們都必須實現onCommand（命令，參數）。
CommandChain有addCommand（）方法來註冊它內的新命令，runCommand（）它接受一個命令名及其參數。這個方法應該遍歷命令列表，直到其中的一個響應，執行相應的操作併發送正常。責任
正如我在一些網站已經看到了
鏈，這將是幾乎相同的，與此不同： 而不是一類存儲命令列表循環的通過，每個命令實例都會存儲對下一個命令實例的引用。
那麼，這種差異是否足夠大以考慮兩種設計模式的不同？
它們在哪些實際情況下適用？
它們是相同的設計模式。
如果它們具有相同的屬性並且只有實現不同，它們在功能上是相同的。這表明這兩種設計模式是一樣的。
另一個提示是，有對責任DP鏈維基百科頁面，但沒有對指揮鏈。
的「四人幫」是誰寫的開創性的書上分別檢測點上的行爲和屬性，而不是實現非常清晰的，明確的設計模式。
它看起來像使用命令的那家連鎖店時，有一個單獨的處理器需要基於一些請求，而在責任鏈另一方面用於執行多種任務時，每個處理器只能處理一個類型的請求。 一個例子可能是如果有火警，那麼你可以向火災檢測器發出一個請求，而不是發出很多命令來檢查不同級別或地方的火災。 雖然誰會像消防員那樣對這場火災作出迴應，但是保安，警察等可以通過使用責任鏈來完成。
這個例子中清除出去，但它是完美知道在網絡發展兩個模式的一些實際情況。 –
的責任鏈是四人原創設計王剛之一，你可以找到在PHP在這裏實現了幾個例子：
http://www.php5dp.com/category/design-patterns/chain-of-responsibility/
一個使用該模式一直以「嗅探器」程序用於選擇適用於不同設備（手機，平板電腦，臺式機）具有多種配置的網站的正確設備。 CoR模式避免了發出請求的客戶端和處理對象之間的耦合。
它不是一個層次「處理對象」是不是另一個上方，但在它通過一組選項，直到找到最適合給定的要求是連續的。
「命令鏈」可以是用於COR用詞不當或者它可以是一個完全不同的模式與分級結構。
他們有相同的行爲畢竟，即使第一次一個存儲在主類的屬性的處理程序，並在第二屆每個處理器包含參考下一個。我認爲這也可能是決定他們考慮他們不同的模式。 什麼樣的實現可能會更好，正如我問Atul：在Web開發中通常情況下這種模式是否適用？ –
如果處理程序的＃趨向於被固定的和已知的在它們被建立時，像第一一個的實現是從性能的角度來看優選的，因爲你可以然後分配處理程序作爲一個數組。這保存了參考公關的指針。處理程序。至於模式的適用性：許多情況。通常當你想有一些默認行爲（鏈的末尾，一個全部處理程序）和幾個「特例」處理程序。 –