1,077
社区成员
发帖
与我相关
我的任务
分享[转载]面向过程→ 面向对象→ 面向组件！
在软件界流传着这样一种看法，随着技术的进步，每十年便会出现一种主流的计算平台，编程语言和程序设计思想。80年代是Unix/C和面向过程，90年代是Windows/C++和面向对象，当今则是.NET/C#和面向组件。.NET旗帜鲜明地提出下一代软件的构建思想--面向组件，和构建平台--XML Web Services，C#为此量身定做，生逢其时。只有洞悉了其仰仗的平台和程序设计思想，我们才能清晰地把握由C/C++到C#这一锐利之路的精神命脉。在这样的平台和思想的基石上，C#主要从以下四个方面对C++进行了显著的革新和提高：
明晰，简练的语法风格
托管，安全的执行环境
高效，内置的XML Web Services支持
直接，丰富的组件编程支持
在这中间，组件支持是C#语言的灵魂，也是本文在阐述从C/C++向C#转型过程中着墨最多的地方。值得指出的是本文中的C/C++指传统C/C++，不包括微软对C++进行托管包装后的Managed C++，因为它更多的是为原先的C++的代码向.NET平台提供转换支持，在这里不具比较意义。下面本文将从上述四个方面来阐述。
C#在和C++语法风格保持了高度一致的同时，摈除了很多晦涩不清，繁荣拖沓的表达。赋值等号和判断等号严格区分彻底消除了C++中赋值与判断同时表达的危险。单根继承加上多接口实现的支持，使C#杜绝了C++晦涩不清的多继承。数值类型和对象之间转换的box/unbox操作，兼顾了数值运算的性能和面向对象的统一。声明与实现同归一处使得C#中再也没有C++头文件的烦恼。在方法及其参数传递方面，C#摈弃了指针与地址操作及const 修饰，代之以引用（ref），输出（out），数组（params）这样一些表义明确的修饰符。foreach语句使得集合中的元素的遍历更加方便和优雅。C#也对操作符重载进行了更为严格规定和有限的支持。“不安全的转型操作，数组索引越界，未初始化变量”等在C++中经常出现的错误在这里将不再可能。
.NET平台为C#引入的安全，高效的托管执行环境--通用语言运行时（CLR）引人注目。内存泄漏一直以来都是C/C++程序界的一个顽疾。把这样容易出错而又繁重的任务交给系统处理，将程序员从中解脱出来专注于事务逻辑的实现，已经成为软件业的共识。自动垃圾收集改变了C++中内存管理的方式，在C#中程序员甚至不需要有内存管理这样的概念--实际上我们根本找不到类似delete这样的内存释放指令。强健的异常处理极大地提高了C#开发软件的纠错能力，绝非传统C++中错误代码返回值所能企及。类型安全在C#语言中被提到了一个相当的高度，对任何数据的任何操作都被CLR所监视，并严格限定在该数据类型所支持的范围内，转型操作也被严格定义。和传统COM组件及DLL的互操作性使得C#和传统C++实现了交互访问能力，这种改良而非革命的策略对C++程序员非常重要。基于IL中间语言（C#的目标编译语言）的JIT编译技术在实现其跨平台编程的许诺的同时，更是使得C#可以同多达20多种主流开发语言实现对象级的互操作，这令人异常震惊和兴奋。
Web 服务为当今产业界公认的下一代网络计算的方向，它一个基于因特网的应用程序模块，在遵守由一个协议集组成的特殊的技术规格下进行对象组件之间的远程交互。.NET平台直接在IL中间语言中内置对XML Web Services的操作支持更是传统C++所非企及，这使得C#与生俱来地获得下一代网络编程语言的美名。在C#下的XML Web Services编程，开发人员面对的将是一个友好的由商业组件组成的对象结构，而不是HTTP，SOAP，UDDI，WSDL等底层协议。
历史是一面镜子，回顾一下软件开发走过的路子对我们理解C#及其倡导的组件编程思想将很有启发。在早期Unix和C主导的时代，“数据结构+算法”成为我们构建软件的唯一方式，按字母排序的API函数集成为我们编程的圣经。然而我们不能忍受这种扁平的API组织结构给我们带来的现实逻辑和机器实现之间的巨大鸿沟，近乎相同的软件被我们低效地一遍一遍重写。千呼万唤始出来，一时间C++和面向对象技术于是成为我们的口头语，绚丽多彩的Windows成为我们的栖息地，MFC类库及由其主导开发的各种桌面软件成为C++历史上的极盛时期。然而，随着软件规模越来越大，面向Web应用的需求越来越高，源代码级的对象复用显然已经不能满足我们的需要。修修补补的COM组件技术登上历史舞台，然而由于C++语言底层机制带来的结构性矛盾，各种问题接踵而来：IDL拖沓繁冗，“DLL-Hell”噩梦连绵，二进制流在防火墙的阻隔下举步维艰......我们迫切需要一个面向Internet异构体系，为软件提供像IC电路元件一样的可插拔的标准封装和复用方式的组件构造平台，.NET和C#应运而生。组件编程是C#将C++及其面向对象技术从软件设计开发阶段向软件发布，运行，管理的合理延伸。C#在面向对象的基础上直接引入接口，属性，方法，事件，特征，文档化等组件特性，为其RAD开发提供第一等的支持。内置语言的元数据映射机制彻底解除了IDL，GUID以及COM接口等繁冗的编程任务，使得组件得以廉价地实现自描述，并且革新了传统C++的代码编写方式。“side by side”的执行方式解决了长期以来困扰程序员的“DLL-Hell”，多个版本的组件可以相安无事地同时运行于一个系统内。简化了的XCopy安装方式使得繁琐的注册表不再成为安装程序的必须，“拷贝，然后运行”--程序本来就应该是这个样子！
“用C++同样可以进行组件开发！”没错，但就像我们可以用C来实现面向对象的技术一样，我们完全可以用“近乎高超”的技巧来为C++进行组件开发提供各种论据。但且不说这种间接的，晦涩的开发策略会在多大程度上损伤我们的对于组件编程思想的表达，光是它带来的各种琐碎和不安全的纰漏就曾令多少程序员噩梦不断！组件编程不仅是编程元素的改变，更是程序设计思想的革新！ 一个典型的C#程序设计能使我们更真切地体会从C++对象编程到C#组件编程的转型过程。我们首先思考的是我们能否把我们的问题组件化？我们是否在编写一个可复用组件？我们要为我们的组件添加诸如接口，属性，方法，事件，特征，文档吗？我们是否可以为我们组件提供RAD重用开发支持？一切OK！我们无需再关心诸如内存泄漏，多版本安装，IDL，GUID等等繁琐的细节--而这正是现时我们在C++下设计完类后花费很多时间和精力的地方。编程的本质是创造服务，而非驯服机器，C#还编程以它本来的面貌。
当然我们决非要C#替代C/C++，我们所竭力伸张的是在现时主流的开发需求和潮流下的选择导向。C#也绝非完美，比如在C++中很好用的模板在C#中就没有实现（微软正在研发当中）。对机器的表达也绝非C++的犀利所媲--当然这是问题的另一个方面。C++在对机器底层操作要求较高的编程环境如：实时应用，系统内核，硬件驱动等方面仍然保持其统治地位。只有理解了整个软件业的当下需求和未来方向，真正把握了C#语言根深蒂固的组件编程设计思想，我们才能根据我们的实际需要而非喧闹争论得出适合自己的结论，完成从C/C++到C#的锐利之路！
明晰，简练的语法风格
托管，安全的执行环境
高效，内置的XML Web Services支持
直接，丰富的组件编程支持
在这中间，组件支持是C#语言的灵魂，也是本文在阐述从C/C++向C#转型过程中着墨最多的地方。值得指出的是本文中的C/C++指传统C/C++，不包括微软对C++进行托管包装后的Managed C++，因为它更多的是为原先的C++的代码向.NET平台提供转换支持，在这里不具比较意义。下面本文将从上述四个方面来阐述。
C#在和C++语法风格保持了高度一致的同时，摈除了很多晦涩不清，繁荣拖沓的表达。赋值等号和判断等号严格区分彻底消除了C++中赋值与判断同时表达的危险。单根继承加上多接口实现的支持，使C#杜绝了C++晦涩不清的多继承。数值类型和对象之间转换的box/unbox操作，兼顾了数值运算的性能和面向对象的统一。声明与实现同归一处使得C#中再也没有C++头文件的烦恼。在方法及其参数传递方面，C#摈弃了指针与地址操作及const 修饰，代之以引用（ref），输出（out），数组（params）这样一些表义明确的修饰符。foreach语句使得集合中的元素的遍历更加方便和优雅。C#也对操作符重载进行了更为严格规定和有限的支持。“不安全的转型操作，数组索引越界，未初始化变量”等在C++中经常出现的错误在这里将不再可能。
.NET平台为C#引入的安全，高效的托管执行环境--通用语言运行时（CLR）引人注目。内存泄漏一直以来都是C/C++程序界的一个顽疾。把这样容易出错而又繁重的任务交给系统处理，将程序员从中解脱出来专注于事务逻辑的实现，已经成为软件业的共识。自动垃圾收集改变了C++中内存管理的方式，在C#中程序员甚至不需要有内存管理这样的概念--实际上我们根本找不到类似delete这样的内存释放指令。强健的异常处理极大地提高了C#开发软件的纠错能力，绝非传统C++中错误代码返回值所能企及。类型安全在C#语言中被提到了一个相当的高度，对任何数据的任何操作都被CLR所监视，并严格限定在该数据类型所支持的范围内，转型操作也被严格定义。和传统COM组件及DLL的互操作性使得C#和传统C++实现了交互访问能力，这种改良而非革命的策略对C++程序员非常重要。基于IL中间语言（C#的目标编译语言）的JIT编译技术在实现其跨平台编程的许诺的同时，更是使得C#可以同多达20多种主流开发语言实现对象级的互操作，这令人异常震惊和兴奋。
Web 服务为当今产业界公认的下一代网络计算的方向，它一个基于因特网的应用程序模块，在遵守由一个协议集组成的特殊的技术规格下进行对象组件之间的远程交互。.NET平台直接在IL中间语言中内置对XML Web Services的操作支持更是传统C++所非企及，这使得C#与生俱来地获得下一代网络编程语言的美名。在C#下的XML Web Services编程，开发人员面对的将是一个友好的由商业组件组成的对象结构，而不是HTTP，SOAP，UDDI，WSDL等底层协议。
历史是一面镜子，回顾一下软件开发走过的路子对我们理解C#及其倡导的组件编程思想将很有启发。在早期Unix和C主导的时代，“数据结构+算法”成为我们构建软件的唯一方式，按字母排序的API函数集成为我们编程的圣经。然而我们不能忍受这种扁平的API组织结构给我们带来的现实逻辑和机器实现之间的巨大鸿沟，近乎相同的软件被我们低效地一遍一遍重写。千呼万唤始出来，一时间C++和面向对象技术于是成为我们的口头语，绚丽多彩的Windows成为我们的栖息地，MFC类库及由其主导开发的各种桌面软件成为C++历史上的极盛时期。然而，随着软件规模越来越大，面向Web应用的需求越来越高，源代码级的对象复用显然已经不能满足我们的需要。修修补补的COM组件技术登上历史舞台，然而由于C++语言底层机制带来的结构性矛盾，各种问题接踵而来：IDL拖沓繁冗，“DLL-Hell”噩梦连绵，二进制流在防火墙的阻隔下举步维艰......我们迫切需要一个面向Internet异构体系，为软件提供像IC电路元件一样的可插拔的标准封装和复用方式的组件构造平台，.NET和C#应运而生。组件编程是C#将C++及其面向对象技术从软件设计开发阶段向软件发布，运行，管理的合理延伸。C#在面向对象的基础上直接引入接口，属性，方法，事件，特征，文档化等组件特性，为其RAD开发提供第一等的支持。内置语言的元数据映射机制彻底解除了IDL，GUID以及COM接口等繁冗的编程任务，使得组件得以廉价地实现自描述，并且革新了传统C++的代码编写方式。“side by side”的执行方式解决了长期以来困扰程序员的“DLL-Hell”，多个版本的组件可以相安无事地同时运行于一个系统内。简化了的XCopy安装方式使得繁琐的注册表不再成为安装程序的必须，“拷贝，然后运行”--程序本来就应该是这个样子！
“用C++同样可以进行组件开发！”没错，但就像我们可以用C来实现面向对象的技术一样，我们完全可以用“近乎高超”的技巧来为C++进行组件开发提供各种论据。但且不说这种间接的，晦涩的开发策略会在多大程度上损伤我们的对于组件编程思想的表达，光是它带来的各种琐碎和不安全的纰漏就曾令多少程序员噩梦不断！组件编程不仅是编程元素的改变，更是程序设计思想的革新！ 一个典型的C#程序设计能使我们更真切地体会从C++对象编程到C#组件编程的转型过程。我们首先思考的是我们能否把我们的问题组件化？我们是否在编写一个可复用组件？我们要为我们的组件添加诸如接口，属性，方法，事件，特征，文档吗？我们是否可以为我们组件提供RAD重用开发支持？一切OK！我们无需再关心诸如内存泄漏，多版本安装，IDL，GUID等等繁琐的细节--而这正是现时我们在C++下设计完类后花费很多时间和精力的地方。编程的本质是创造服务，而非驯服机器，C#还编程以它本来的面貌。
当然我们决非要C#替代C/C++，我们所竭力伸张的是在现时主流的开发需求和潮流下的选择导向。C#也绝非完美，比如在C++中很好用的模板在C#中就没有实现（微软正在研发当中）。对机器的表达也绝非C++的犀利所媲--当然这是问题的另一个方面。C++在对机器底层操作要求较高的编程环境如：实时应用，系统内核，硬件驱动等方面仍然保持其统治地位。只有理解了整个软件业的当下需求和未来方向，真正把握了C#语言根深蒂固的组件编程设计思想，我们才能根据我们的实际需要而非喧闹争论得出适合自己的结论，完成从C/C++到C#的锐利之路！
...全文
请发表友善的回复…
发表回复
