有很多人經(jīng)常會持有這樣的疑問：為什么 .NET 框架要把一些很簡單的功能也封裝起來？而有些人所堅持的“有現(xiàn)成的就用現(xiàn)成的”的習慣在那些“明明只是很簡單的功能卻被封裝了起來”的情況下也顯得很可笑。那么，實際上到底有沒有必要用那些本來就很簡單的封裝？這些簡單的封裝到底具有什么樣的意義呢？

　　其實大部分這樣的簡單的封裝都是針對“跨平臺使用”而設計的。有些人可能會說：.NET 框架有什么跨平臺可言？其實 .NET 框架雖然現(xiàn)在只提供 Windows 上的版本，但其它平臺上的 CLI 實現(xiàn)，如 Mono、DotGNU 等等也都有賴于 .NET 框架和 CLI 的預見性方能成為現(xiàn)實；而可以在多種環(huán)境中使用的 RIA 平臺 Silverlight 也是將這種思想發(fā)揮到了極致。

　　舉個例子來說，.NET 框架中 IPAddress 類型具有 NETworkToHostOrder 和 HostToNETworkOrder 方法，如果你使用 Reflector 來查看反編譯后的代碼，你會發(fā)現(xiàn) NETworkToHostOrder 只是調用了 HostToNETworkOrder，而 HostToNETworkOrder 的原理也只不過是一些簡單的位移運算而已。

　　有的人看到這里可能會想：包了兩層方法性能多差啊，用到它的地方自己寫位移運算不是也可以么？不要這樣做。實際上，CLR 的 JIT 編譯功能會把簡單的方法進行內聯(lián)編譯，所以像是 NETworkToHostOrder 這樣的方法在進行 JIT 編譯之后結果和直接使用位移運算并沒有區(qū)別，而在這里偏執(zhí)地直接使用位移運算，不僅性能沒有實質上的提升，還會導致代碼難以維護；而且這樣的代碼如果到了使用 Big-Endian 字節(jié)序的計算機上，就不能用了！

　　當然了，如果你善于使用預編譯指令之類的工具，這種問題也自然難不倒你。

　　與此相似的，還有：有些具有 Visual Basic 5/6 編程經(jīng)驗的人在使用 Win32API 的時候會習慣使用 Long 或者 Int32 來當作各種 Handle 的等價類型，然而這樣做是錯的！如果你去查看 SDK 中關于 HANDLE 的定義，你會發(fā)現(xiàn)：

typedef PVOID HANDLE;

NET技術：.NET框架：為什么我們要盡量使用框架內建的功能，而不是重新發(fā)明，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。