由C#谈起
软件技术风云变幻、日新月异 ,让人眼花潦乱, 软件技术正进入了虚拟时代, 嘿嘿, 大家是否已经作好准备了.当然万变不离其宗,基础知识还是很重要.
如果说C++是灵活高效, 则C#是(模块)简洁,人性化,符合Anders Hejlsberg的一贯风格.
学过Delphi的会发现, is/as运算符; 如Item类,里面的方法与属性几乎一样;在事件中回传sender引用也差不多;WinForm类的继承体系等, 这并不奇怪, 都是大师Anders Hejlsberg的作品, 应该这种模式已经比较完美.我觉得Anders Hejlsberg做C#时, 比做Delphi时,在模式上有很大进步, 当然Delphi在做DB方面不错.看看这个就知道了.
我觉得Anders Hejlsberg做C#时, 比做Delphi时,在模式上有很大进步, 当然Delphi在做DB方面不错.看看这个就知道了.
在Delphi中是 在C#中是
TObject Object
TPersistent MarshalByRefObject
TComponent Component
TControl Control
TWinControl
TScrollingWinControl ScrollableControl
TCustomForm ContainerControl
TForm Form
不当是这个, 里面的方法和属性也何其相似. 可见熟悉Delphi的兄弟有很多好处的.
C#是很大的特色就是人性化, 如reflection/persistence/serialze/ Remoting (与java类似),但更加出色,功能延展的很好.
.NET体系框中非常注意设计模式(JAVA也不错),如System下的各种分类, System.Convert中的类型转换模式,简洁清晰. .NET处理数据库的模式也不错.如SqlDataReaderod系列类, 减少了耦合, 融洽得不错.
Assembly包含模块，而模块包含类型，类型又包含成员。Assembly是通过元元素描述自身，创意很好，不象COM组件一样, 每个组件都需要注册, Assembly这种机制是通过reflection来实现, 不知EJB组件是否很好可以自我描述. 这说明.NET的组件模型有了新的进步.
MFC中CObject就做得不够好, 它不能保证接口的最小,相对于C#/VCL就差得多.而C#/VCL 经过一系列的单根继承体系, 分解得很好, 这是MFC的一大缺点, 举个例子, 如果我从CObject下继承一个类, 仔细想一想,是不是接口太大? 有些根本不需要, 我觉着, 最起码,应从CObject下多继承一层, 尽量保持接口最小的原则.
在C#,把namespace发挥得极佳, 我想, 及其它也遵守一个OO原则, 在有需求点的地方抽象, 于是就有了namespace.看看,所有的C#里的东西是不是都可以用OO的思想来理解?
MFC中CObject就做得不够好, 它不能保证接口的最小,相对于C#/VCL就好得多. 经过一系列的单根继承体系, 分解得很好, 这是MFC的一大缺点, 举个例子, 如果我从Cobject下继承一个类, 仔细想一想,是不是接口太大? 有些根本不需要, 我觉着, 最起码,应从CObject下多继承一层, 尽量保持接口最小的原则.
在C#,把namespace发挥得极佳, 我想, 及其它也遵守一个OO原则, 在有需求点的地方抽象, 于是就有了namespace.看看,所有的C#里的东西是不是都可以用OO的思想来理解?
我认为C#可以增加的东东:
1. 在一此些情况下,也允许类不从Object类下继承, 因为它强制了我们的设计的思路,但相对比较简单, 没有了灵活性.
2. GP支持,但GP好象还不是非常成熟, 好象下一版将支持
由于第一次写文章, 有不对的地方还请指教. 我的QQ是48488278.
