作爲（缺少）語言功能的設計模式

有時，人們將設計模式稱爲缺少編程語言功能。爲了避免關於什麼是設計模式的爭論，讓我們假設我們只考慮原始的GoF模式。例如，單例模式在使用關鍵字object支持單例對象的Scala中消失。作爲（缺少）語言功能的設計模式

關於此問題的資源很少，特別是來自C2 wiki的Are Design Patterns Missing Language Features或來自SO的Are design patterns really language weaknesses?。但我無法找到對這個問題的非客觀，客觀和全面的報道。理想情況下，我想要一個帶有GoF設計模式（行）和一些主流編程語言（列）的矩陣，其中每個單元格都會引用關於特定編程語言中模式的討論。我們也可以解決這個問題並選擇：Java（作爲靜態類型的OO代表），Smalltalk（作爲動態類型代表），Haskell（作爲功能代表），Scala （作爲混合oo /功能代表），Lisp（作爲元編程代表），JavaScript（作爲基於原型的代表）。並留下其他PL的旁註或評論。我知道我們可以爭論這個選擇，但這對於這些語言來說已經很有意思了。

無論如何，這將永遠是一個懸而未決的問題，但我覺得就這樣問，這足夠集中，有一個最佳答案。

也許這個矩陣已經存在的地方？或者有人有足夠的知識來製作它？或者有人足夠敏銳地開始並使其成爲維基答案，以便其他人可以繼續？

來源

2010-10-27 ewernli

而不是在SO上提出一個開放式的主觀問題，你爲什麼不寫一個博客文章，並發現它，因爲你發現一個模式的新實現？ – slugster 2010-10-27 01:32:04

這不可能有一個最佳答案。我會投票給社區wiki。 – 2010-10-27 01:33:14

@slugster我的想法確實是撰寫這樣一篇博客文章（或我的一位朋友會這樣做），而問題是收集有關特定模式w.r.t對給定語言的最佳討論的參考。然後我可以將它編譯成博客條目。同時，我可能也會回答我自己的問題，並草擬矩陣的草稿。 – ewernli 2010-10-27 02:05:29

設計模式中的模式是人們在使用不同語言進行編程時不斷增加的一組模式的子集。作者非常清楚，這些模式只適用於OOP語言，所以其中許多模式在這種情況之外是沒有意義的。

同時，在OOP語言中不需要其他語言的大量模式。考慮在C或Scheme中實現時，對象本身就是一種模式。在彙編中，調用堆棧是一種模式。

來源

2010-10-27 01:45:45 munificent

+1，我寫了OO C代碼（和狀態機C代碼，可以非常相似）。我想說的是，在任何具有超過100K代碼空間的設備上，用匯編語言編寫的調用堆棧不僅僅是一種模式，而是一種幫助。 – detly 2010-10-27 01:54:34

正確，某些模式不適用於其他上下文。對我來說，跳過根本不相關的模式也沒有問題，或者提出一種模式在另一種語言/模式中根本沒有意義時。但我覺得下面的模式應該在OO上下文之外進行討論：適配器，裝飾器，代理，命令，解釋器，觀察者，狀態，策略，訪問者。是的，有很多模式和語言，所以我必須以某種方式限制問題的範圍。 – ewernli 2010-10-27 02:13:10

我個人在花了幾年的時間做OOP之後發現設計模式的問題在於他們確實突出了OOP的問題以及看到與域中的相關數據中的模式有多難它正在建模。有時很難看到樹木的木材。 OOP中的一些文物只是爲了解決思考特定範例時存在的問題，或者解決封裝狀態和訪問問題。

我認爲設計模式非常好，我使用它們，但是它們一直被認爲是解決OOP無法客觀地處理數據結構和功能的問題的一種解決方案，因此經過驗證的公式可以應用。一個簡單的例子就是Singleton對象。這在使用函數式語言時就會消失，而不是問題。

正如SO上的一位紳士所說，當我問及UML的問題以及它是否可以用來模擬功能語言時，他說功能性編程語言的建模語言是數學。我認爲這是理解爲什麼模式與函數式編程語言無關的關鍵，因爲它們背後的理論深深地植根於數學結構中。

我無法幫助您選擇一張嬰兒牀牀單，但我可以肯定的是，GOF模式不適用於函數式編程語言，因爲它們直接涉及到數學的真實模式，因爲功能性語言的美妙之處在於他們直接（在大多數情況下）映射到解決數學問題的許多年。也許一個莽撞的說法是，函數式語言的設計模式是具有一對一關係的數學定理，其中OO具有一種有時妨礙人爲抽象的形式。

我認爲有些設計原則可以針對所有語言（如MVC，多層體系結構，擴展和擴展）進行交叉。但是這些我認爲不是設計模式，更多的是好的軟件設計實踐。

來源

2010-10-27 02:54:10 WeNeedAnswers

你實際上說的是，當使用其他語言時，某種模式消失，實際上我想調查。也許我應該首先從提取GoF模式解決的問題開始，然後看看如何用其他語言解決問題。例如。對象或數據結構唯一性的問題在面向對象的單例中被解決，並以嚴格的功能語言消失。或者Haskell類型類和複合模式之間是否存在某種概念關係？當然，我有點比較蘋果和橘子，但這很有趣。 – ewernli 2010-10-27 16:13:35

或者在OO中使用訪問者來解釋AST時，如果因爲超載而無需功能（請參閱表達式問題），這一事實。或者消失的解釋器模式是PL支持元編程。或者適配器，如果你有類似Scala的隱式和提取器等等。 – ewernli 2010-10-27 16:16:27

是的，我也對比較感興趣。 GOF模式確實與面向對象設計有關，我認爲它們所代表的並不是什麼新東西，但它們確實使得像我這樣的日常喬可以訪問模式/算法。在所有的無知中，我只是把它們作爲指導原則，但是在深入研究功能性風格之後，我開始意識到它們有更多的深度。訪問者模式是一個經典的OO示例，它基本上是將一種形式轉換爲另一種形式的函數。 – WeNeedAnswers 2010-10-27 16:26:22

作爲（缺少）語言功能的設計模式

回答

相關問題