語言集成的設計模式

我注意到，在開始設計模式對於初學者來說相當困難。瞭解設計模式結構需要很多時間。將設計模式應用於練習需要很多時間。同意，如果您不熟悉這些設計模式，您將無法第一次看到各種設計模式之間的差異。如果你的類有合適的名字，這個問題就部分解決了。如果您錯過了偶然編寫代碼的一些規則，或者您在設計模式方面經驗不足，那麼您也可以打破您實現的設計模式類結構。編譯器可以保護你並幫助你實現接口 - 如果你沒有實現接口，你不能編譯你的應用程序。這是一個很好和安全的方法。如果編譯器可以保護你，當你實現設計模式類呢？看，很多編程語言都支持「foreach」語句。如果編程語言可以爲工廠，橋樑，代理，紀念品等提供支持？如果它可能是真實的，你可以使用類似下面的申請抽象與具體的工廠模式（我喜歡C＃作爲僞基本語言;它假定上下文關鍵字使用）：語言集成的設計模式

public abstract factory class AF { 
    public product AP1 GetProduct1(); 
    public product AP2 GetProduct2(); 
}; 

public concrete factory class CF1 : AF { 
    public product CP1 GetProduct1() { ... } 
    public product CP2 GetProduct2() { ... } 
};

它認爲它可以幫助您瞭解新的來源並保持應用程序源代碼結構的完整性。你怎麼看待這件事？

來源

2009-12-09 Lyubomyr Shaydariv

我覺得你完全誤解模式是什麼樣的設計。 – 2009-12-09 10:16:13

如果我理解你說的話，你認爲新的語言功能，應該克服通常與實現設計模式相關的樣板代碼的需要。

這已經發生了，這是什麼新鮮事。

採取單，例如，最廣爲人知的模式之一。每個人都知道如何實現它：您聲明構造函數private，將該對象的一個全局實例保存爲static屬性，並添加一個public方法來檢索它。

它的代碼是什麼概念很簡單不少行。

在Scala中，你不需要任何樣板創建一個單例。爲了補充class關鍵字，Scala有一個object關鍵字，它聲明瞭一個單獨的對象：

object MainApp { 
    def main(args: Array[String]) { 
    println("Hello, world!") 
    } 
}

在運行時會出現一個單一的全球MainApp實例。沒有必要使用new來實例化它;事實上，你根本不能使用new MainApp。

來源

2009-12-09 10:23:42

您僅爲單身人士提供了一個樣本，這是最簡單的模式之一。但無論如何，我看到我對設計模式使用方法只有另一種看法。謝謝。 – 2009-12-09 10:36:14

你能在Scala中使用這種方法做一個懶惰的初始化單例嗎？ – MHarris 2009-12-09 10:43:42

有一種觀點認爲，語言中設計模式的存在表明語言本身的設計存在弱點，下一代語言應該從上一代常見的設計模式中學習。

例如，請參閱Peter Norvigs famous presentation關於動態語言中不可見的設計模式。實際上，很容易想出已經發生的這個過程的例子 - 正如你所說，foreach循環可以說是嵌入式迭代器，Ruby有一個Singleton mixin可以繼承，任何具有multimethods的語言都不需要Visitor模式。 Groovy擁有內置的構建器。

您的工廠的具體示例聽起來有點像Noop將依賴注入集成到語言規範中。

當然只有這麼遠一個類型檢查可以去保證（目前）的代碼的正確性。將設計模式嵌入語言並不會消除熟悉核心概念的必要性，也不會去思考如何應用這個問題。

你舉的例子很有意思，你建議增加幾個關鍵字和規則是（和我沒那麼熟悉C＃）語言加上沒有明確的益處。「factory」關鍵字告訴類型檢查器（或另一個程序員）將「AF」聲明爲等同於Java接口並且將「product」作爲其方法的返回類型時不清楚？

來源

2009-12-09 10:42:10 MHarris

感謝您的回覆和介紹。一有足夠的空閒時間，我會盡快學習。「工廠」上下文關鍵字會將「產品」方法傳遞到類中。因此，當另一個類從類派生時，編譯器可以檢查是否所有產品都被正確描述。我發現它與接口方法類似，但據我所知，接口和工廠類有些不同。 – 2009-12-09 10:53:25

我認爲你是對的東西。但是，在你錯過了這一點（在我看來）是你要指定一個設計模式，其中，作爲MHarris說，他們往往隨着時間的推移變得過時的或過時，它們依賴的語言不是這樣的好主意。

我認爲那是什麼，有可能是一個「複合」的語言，在這裏你有兩個工件：設計規範語言（耦合到實現語言，不要以爲UML）和實現。所以，把你的例子，這是可以做到這樣的：

設計規範：

single public Factory 
    methods: 
     T Get[T]

請注意，如果做到這樣，因爲設計規範，就是要抽象（不需要指定低在那裏，然後）的水平細節，它可以有便於編寫規範的結構。要知道，在規範中，如果方法是公有或私有的，設計規範（不包括算法僞代碼）只需關注公開可見的行爲，而不關注私有實現細節。

實施：可用於

public class ConcreteFactory : Factory { 
    public Product1 GetProduct1() { ... } 
    public Product2 GetProduct2() { ... } 
};

下面兩種方法：

編譯器可以把設計當作擺設，然後檢查是否實現代碼是一致的吧。
編譯器或運行時可以提供可以自動生成（如單實現）的實現的一部分，以及將碼本身可以假定其獨立的，並沒有必要重新指定，例如：

類ConcreteFactory：工廠{
```
Product1 GetProduct1 { new ConcreteProduct1 } 

    Product2 GetProduct2 { new ConcreteProduct2 } 
```
}

注意，實現可以忽略更高層次的東西，如知名度的類和方法的可見性，因爲這已經在設計級（DRY）指定。如果你問我，這種類型的語言也必須附帶一個專門的IDE，以便提供關於類型設計的上下文信息。正如Jeff Atwood所評論的那樣，任何新的語言都應該包含專門的IDE。

來源

2012-10-07 06:53:26

是的，時間過去了，即使對我來說現在的問題也很老舊，但是謝謝你的回覆。 :)關於你稱之爲複合語言的問題，我對編譯時宏有類似的想法，可能會擴展到目標語言。然而，我不確定那些宏可能允許自由語法（這樣的宏肯定會使複合語言編譯器變得更復雜）：在Java中，我有時會錯過像'class XDecorator裝飾X {...}'的地方'裝飾'可以用一個宏來定義，但解析'裝飾（X，{...}）'比類定義更糟糕。 – 2012-10-07 08:04:10

哈哈，是的，但我想過類似於您的問題，並搜索了「集成設計」或「語言集成設計」，並且您的問題在Google搜索中排名第一，有點不爽嗎？ – 2012-10-07 14:42:11

是的，我不時嘗試谷歌的東西，我一次又一次地到這裏。 :)無論如何，謝謝你的評論。 – 2012-10-07 16:51:34

語言集成的設計模式

回答

相關問題