.NET框架:为什么我们要尽量使用框架内建的功能,而不是重新发明

  有很多人经常会持有这样的疑问:为什么 .NET 框架要把一些很简单的功能也封装起来?而有些人所坚持的“有现成的就用现成的”的习惯在那些“明明只是很简单的功能却被封装了起来”的情况下也显得很可笑。那么,实际上到底有没有必要用那些本来就很简单的封装?这些简单的封装到底具有什么样的意义呢?

  其实大部分这样的简单的封装都是针对“跨平台使用”而设计的。有些人可能会说:.NET 框架有什么跨平台可言?其实 .NET 框架虽然现在只提供 Windows 上的版本,但其它平台上的 CLI 实现,如 Mono、DotGNU 等等也都有赖于 .NET 框架和 CLI 的预见性方能成为现实;而可以在多种环境中使用的 RIA 平台 Silverlight 也是将这种思想发挥到了极致。

  举个例子来说,.NET 框架中 IPAddress 类型具有 NETworkToHostOrder 和 HostToNETworkOrder 方法,如果你使用 Reflector 来查看反编译后的代码,你会发现 NETworkToHostOrder 只是调用了 HostToNETworkOrder,而 HostToNETworkOrder 的原理也只不过是一些简单的位移运算而已。

  有的人看到这里可能会想:包了两层方法性能多差啊,用到它的地方自己写位移运算不是也可以么?不要这样做。实际上,CLR 的 JIT 编译功能会把简单的方法进行内联编译,所以像是 NETworkToHostOrder 这样的方法在进行 JIT 编译之后结果和直接使用位移运算并没有区别,而在这里偏执地直接使用位移运算,不仅性能没有实质上的提升,还会导致代码难以维护;而且这样的代码如果到了使用 Big-Endian 字节序的计算机上,就不能用了!

  当然了,如果你善于使用预编译指令之类的工具,这种问题也自然难不倒你。

  与此相似的,还有:有些具有 Visual Basic 5/6 编程经验的人在使用 Win32API 的时候会习惯使用 Long 或者 Int32 来当作各种 Handle 的等价类型,然而这样做是错的!如果你去查看 SDK 中关于 HANDLE 的定义,你会发现:

typedef PVOID HANDLE;

NET技术.NET框架:为什么我们要尽量使用框架内建的功能,而不是重新发明,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。