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

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

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

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

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

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

typedef PVOID HANDLE;

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

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