本文章是由機器翻譯。

程式設計師雜談

多範型 NET，第 1 部分

Ted Neward

多年來，.NET 社區中的許多人都聽說過 Microsoft 對於 Visual Studio 環境充當的 「 角色 」：愛因斯坦（天才）、貓王（搖滾明星）和莫特（「 普通 」 開發人員）。儘管這些角色可能對 Microsoft 嘗試確切瞭解他們正在為哪些人構建 Visual Studio 和 Microsoft.NET 平臺有用，但我發現它們並不那麼有用。事實上，我逐漸意識到對於絕大部分.net 生態系統來說，開發人員幾乎都屬於兩大基本（且非常老套）的陣營之一：

C + + 的開發人員。 這是開發者學到所有在 「 良好 」 的物件導向方式，並設法在每次的機會建置豐富網域模型，即使寫入批次檔。如果他們的資歷相當老，實際上已非常專業地編寫過 C + +，則他們很可能專注于構建框架和可重用抽象，以致于可能從未交付任何成果。這類開發人員的特徵是擁有自命不凡的態度，並且經常會發現他們自負地引用他人的 「 模式 」 來 「 教育那些不幸聚集在一起卻不了解何謂無名的品質的人們 」。

VB 的開發人員。 這是聽過所有相關的物件、 範本、 程序，及其他項目 hoopla，顯示被 tossed 周圍這些年來，開發人員數十 (年?)，並已穩固地和 resolutely 採用 「 我進行任何動作，只要程式碼的船隻 」 的態度。事實上，這類開發人員太過於注重代碼交付，以致于當被要求在現有表單中添加一個新按鈕時，他們會從頭開始重新編寫全部代碼。這類開發人員以其標誌性的 「 不要告訴我工作原理，只要告訴我怎麼做 」 態度而出名，並且經常會發現他們從 Google 中偷竊代碼並粘貼到自己的程式中（有時是胡亂地），直到程式運行為止。

hate 郵件的 deluge 開始之前先 let’s 移出明顯：這些是總額的鉛版，我當然不手指指向任何人或 implying 任一群組優於其他。（我曾經屬於第一陣營，但如果有誰說那些人要出眾一些，我將會第一個跳出來反對。）

我之所以花大量篇幅說明這兩大陣營的存在，是因為接下來的一系列專欄將更具體地介紹後者，即 VB 開發人員，他們未花很多時間思考軟體設計。但或許令人驚訝的是，我們涉及的內容同時應與第一陣營有關系，因為隨著 Visual Studio 2010 和.NET Framework 4 的發佈，事情變得複雜很多，至少在語言空間方面。如果要在未來十年有任何機會在設計軟體 (或擴充已經設計的軟體)，而不進行到巨大的 puddle 矽 goo 的工作的程式設計人員，會因為它們 multi-paradigm 的設計] 或 [我有來自呼叫 multiparadigmatic 程式設計中取得良好接地。（是的，多模式程式設計是一個自命不凡的名稱。我的 C++ 控告我吧！） 根基表露無遺

多模式設計

術語 「 多模式設計 」 （和概念，如果可以說有一個作者的話）源于解決詹姆斯單Coplien（Addison Wesley Professional，1998）撰寫的 「 C + + Multi-Paradigm 設計 」 一書。根據書名的後部分，可以相對容易地猜測出該書最初以兩個陣營中的哪一個為目標。但是，結果是語言並非談論的重點；Coplien 的觀點在十年後仍能引起共鳴：

… 一個隱藏的危險是 「 物件導向 」 一詞已經成為同義資料表的 「 良好 」。… 在今天 ’s 市場，您可以尋找附加到 imaginable 每個範例的 「 物件 」 標籤。這就導致了混合設計環境，它們是在忠於過去的基礎上構建的，並且通常受到一種需求的支援：即在對舊方法和技術進行投資的基礎上構建。和大部分的這些環境就稱為 「 物件導向 」。這種組合方法的一個責任是它們隱匿某些物件導向設計，以取代原則從他們的位置中的其他方法的中央原則。這些另人費解的設計技術組合可能會導致體系結構災難。… 維護變得非常困難、 整體結構削弱，以及花費極大的能源，讓系統保持在可行。

但純粹的物件也不是解決之道。完善的模式已被面向物件的大肆宣傳邊緣化。-必須以某種方式將物件構建到解決方案中。 當代開發商的腔調是沒有人使用過程分解會出錯，即使是對於批排序常式這就產生了將方釘強制放入圓孔中的設計。

電腦科學領域的歷程記錄被 littered idealistic 解決方案要從其開始幾乎開始的問題：重複的嘗試建立了許多的單一檢視或解決問題的方法給我們在第一個的組合，然後編譯器和一路產生整個 cottage 產業中 「 sucks 您的語言和這裡 ’s 原因 」。更實用的業者 shrugged，然後說 「 時您所需的只是一個鎚，一切看起來像一個 nail 」。當語言成長更複雜的某種方式我們會遺失工具可能實際上用多用途的事實的視野。

對我來說，幾年前在雷德蒙的動態語言峰會上聽 Anders Hejlsberg 暢談 C# 3.0 時獲得了對這個主題的啟發。語言的分類正逐漸消失。 「 正吸收其他語言的一些思想，並闡述了以下意思： 他指出了 C#我們不再能夠說一種語言僅僅是物件導向的語言，或者僅僅是動態語言，因為很多語言都借用了大量不同的思想。”

他的評論反應了 Coplien 十年前的觀點： 「 C + + 的進一步發展 [超越了其前面的模式，如模組化、抽象資料類型、過程和資料結構]，以便在同一起點支援過程、模組、基於物件、物件導向和泛型程式設計。”

C# 又更進了一步，吸收了 3.0 版本中的功能性概念以及 4.0 版本中的動態概念。Visual Basic 在很久以前就具有動態性（雖然通常會受到嘲笑），並且由於 Microsoft 要實現其與 C# 之間的 「 語言相似性 」 的目標，它支援相同的功能。沒有這些隱藏在表面下的其他語言模式，諸如 LINQ 的解決方案實現起來會更加困難，並且會強制開發人員依賴于其他機制（如代碼生成，它本身是元程式設計的一個有趣方面，將會在後面詳細介紹）以 「 繼承自基類 」 無法捕獲的方式來捕獲正常工作系統的核心共同點。

這是我們會探索核心：物件導向] zealots 的世界有 insisted 多年來繼承表示若要重複使用程式碼的最佳方法。「 密封 」 [C#] 或 「 NotInheritable 」 [Visual Basic] 的原因就在於此。 （預設情況下，類未標記為）但是，在從 WinForms 或 ASP.NET 中的表單類繼承時，我們實際上未重寫基類方法；相反，我們提供委託調用。為什麼不直接重寫？為什麼要遭受委託調用這種打擊（雖然可能很小）？為什麼後臺代碼從基於繼承的模型轉為基於部分類的模型？究竟為什麼要有擴展方法？

每個這些問題的答案可以是 (並已!) explained 在物件導向專門用語但根本原因保持不變：不是所有項目可以輕鬆地在傳統的物件設計建構中表示。嘗試發現代碼的共同部分並將它們組合成一個一級構造（物件導向的程式設計認為一級構造是類，結構化程式設計認為一級構造是資料結構，而功能性程式設計認為一級構造是函數，等等）是軟體設計的目的。如果我們可以使用更多方式來改變需要變更的代碼部分，我們就可以更多地編寫系統，並能夠從容應對不斷來電說明 「 只是一件很小的事情，我忘記告訴你了…… 」 的客戶。

作為一個練習，請考慮以下情況：.NET Framework 2.0 引入了泛型（參數化類型）。為什麼呢？從設計的角度來看，它們起什麼作用呢？（為準確起見，諸如 「 它為我們提供類型安全的集合 」 的答案並沒有抓住要點 Windows 通訊基礎以明顯不僅僅是為了提供類型安全的集合的方式大量使用了泛型。）

我們將在下一次談到這一問題。

未完待續！

很明顯，關於這個主題還有很多可以討論的內容-.NET Framework 中存在的每個模式都值得探討和說明，包括代碼（如果第一部分對於正從事開發的開發人員來說有任何意義的話）。後續部分即將發佈，敬請關注。在我們完成之前，我希望（並且相信）您會有許多更好的設計工具來構建優秀的（這裡是指好的抽象、可維護、可擴展和可重用）軟體。

但現在，請重點關注您正在進行的當前設計，並看看能否找出使用其中每個不同模式的某些高級概念的設計部分 - 很顯然，找出物件部分相對較容易，因此請專注于一些其他部分。您的基本代碼（或.NET Framework）中哪些部分本質上是過程或元程式設計？

順便提一下，如果您想要瞭解某個特定主題，歡迎給我留言，我將會考慮嘗試在完成此特定系列後立即將其列入計畫。畢竟在真正意義上，這是你們的專欄。

祝您工作愉快！

Ted Neward 是與 Neward 的主體 (& I)關聯，一個獨立的公司，專精於企業.NET Framework 和 Java 平台的系統。他曾寫過 100 多篇文章，是 C# 領域最優秀的專家之一併且是 INETA 發言人，著作或合著過十幾本書，包括即將出版的《Professional F # 2.0》 (Wrox)。他定期提供諮詢和指導。您可通過 ted@tedneward.com 與他聯繫，也可通過 blogs.tedneward.com 訪問其博客。