軟件測試開發技術.net開發工具LINQ框架設計指南

軟件測試開發技術.net開發工具LINQ框架設計指南 .net開發技術

關鍵字：.net LINQ框架

　　如今，LINQ的版本發布已經塵埃落定，是時候思考如何使用它了。Keith Farmer甚至談到了使用LINQ以消除子類。不過，在我們了解這些之前，還是先看看微軟的官方指南吧。

　　根據框架設計指南的精神，微軟發布了基于LINQ構建框架的設計指南。LINQ框架設計指南涵蓋了諸如API的設計與行為等主題。與很多公司制定的編碼指南不同，它并沒有包含設計的細枝末節，例如命名模式與格式，除非它們牽涉到公有的API庫。

　　大多數框架設計指南最終都能夠找到與FxCOP集成的方式。FxCOP是一個代碼分析工具，它被微軟和其它公司用來確保編碼的一致性。

　　在概括的介紹之后，該文檔介紹了擴展方法(Extension Methods)和泛型委托Func、Action以及Expression。在指南給出的標準警告中，有一個與命名空間沖突無關的指導——它要求在普通方法能夠實現的情況下，不要濫用擴展方法。當兩個庫都公開了相同類型的擴展方法時，會發生方法名稱的沖突。一旦發生，只能導入一個庫，另一個庫則必須使用完整的名稱才能被引用。

　　在擴展LINQ一節中，對于如何命名泛型類型有一個頗有助益的建議。在類型名為S以指代包含元素項的集合時，名為T的泛型類型總是指代集合的元素項(items)。雖然這不是強制性的，但至少有助于閱讀內建方法(built-in methods)。

　　對于性能，指南提出的一個建議是，如果性能牽涉到計算集合的元素總數，則實現ICollection有助于提高性能。當你只能實現IEnumerable時，就必須遍歷整個集合才能得到集合的元素總數。

　　現在，再回頭看看Keith Farmer提到的避免子類的方法：

　　我過去一直在考慮的一件事情是削減類的職責，使其只具備基本的定義：恰如其分的屬性定義，與屬性對應的方法，以及構造器和類型轉換器。

　　然后使用擴展方法定義適當的操作，而不需要維護類作為自身實體的概念，這樣就沒有必要創建子類型了(即使子類型是可行的)。

　　例如，一個Node不需要知道Graph的操作也能夠工作良好，也可以認為Graph不需要了解IsNetworkRouter的內容。

　　在這種情況下，類似于Traverse(GraphLink)這樣的方法就屬于Graph中很好的方法定義，而類似于FindLeastWorkRoute(Node, Node)這樣的方法，由于它依賴于GraphLink的特定子類型的實現細節(即它具有一個關聯的Work衡量標準)，那么在我看來，這樣的方法最好定義為一個擴展方法。

　　如果僅僅是為了實現應用程序特定的邏輯，而去創建一個自定義子類型，就會擾亂我們關注的類(例如，Graph就勝過同時定義Graph和GraphLink)，而通過擴展方法就可以避免這樣的情況。

　　這在.NET編程環境下是有意義的嗎?它是否遵循了微軟的設計原則呢?或者對它而言，有多少是與這些指南相關的呢?

原文轉自：http://www.anti-gravitydesign.com