2007年11月1日 1。访问控制方面:C#有public、internal、protected、private,比java多了个internal,其实它跟java的包访问差不多,internal表示同一个编译集合(如exe、dll)下的类可以互访。 对于protected,java和C#有区别。在java中,protected和包访问级别差不多,即不是私有的。而在C#中,protected和private差不多,即它标志的成员是私有的。 有这样一种情况:类中的一个成员,需要它能被子类访问到,同时能被同一个集合中(无论是java的包还是C#中的编译集合)的其他类访问到,怎么办呢?在java中,只要用protected就行了。在C#中,可以同时指定internal protected(二者的顺序随意)。 在有这样一种情况:类中的一个成员,需要它能被子类访问到,但不能被同一个集合中(无论是java的包还是C#中的编译集合)的其他类访问到,怎么办呢?在C#中,可以指定protected(二者的顺序随意)。但java就无能为力了。
评论:我很喜欢C#的internal,在Java如果一个为API中某些类提供服务的类,为了不对外暴露,只能用包级私有,并和被服务的类放在一个包中,如果有多个包中的类都要被服务,就没法办了。而C#的internal就很好的仅限当前“集合”(可能有多个namespace)中的类访问。
但是,我又不喜欢C#的“集合”的感念。反射的时候还必须给出DLL或EXE的文件名(如果不在当前DLL或EXE中),而Java是不需要的,只有在WEB-INF/classess和lib 下的都可以。特别是当API要反射它的调用者时,作为类库的DLL怎么知道哪个EXE在调用自己?
2。C#中有static constructor的概念,这跟java中的静态初始模块一样。 C# : static [类名]{} java :static{}
批注:原来是这样写,我找了半天也没搜到C#中的静态代码段如何个写法,如今得来全不费工夫。
3。Java中的main函数必须是public static void main(String[] args)的样子,否则虚拟机拒绝运行。C#中,Main函数可以是private的(甚至可以是protected),可以没有参数,可以返回int值。有点像C语言。 4。发现csc.exe有一个功能很好,100后面加一个小写的L,它会警告:“l”后缀容易与数字“1”混淆;为清楚起见,请使用“L”。
批注:MS的人性化关怀呀。
5.C#提供了一种机制,使得某个变量可以被动态赋值一次,以后就不能再改了。那就是readonly关键字的功能。
批注:这个机制可能在特定场合下很有用。比如:抽签,这样你就不能耍赖了。
6.java在继承、多态方面,比C#强多了。Java默认的多态,C#要求加上virtual(被继承的方法)和override(继承的方法),而且C#要求不能改变原来的访问修饰符,不像java那样,可以指定更加宽松的访问方式。如果有人利用C#来写程序,必须经常带上virtual和override,还必须照抄原来的访问控制符,不会很郁闷吗?难道有人用C#的面向对象特性时,会舍弃多态的特性?这会引起多大的混乱啊。 多态是面向对象的精髓,像java那样默认不是更好吗?
批注:C#号称和Java有90%的相似性,但它必将是从C++发展而来的,在虚函数的概念上还是延续着C++的方式。习惯了Java之后,真的是感觉别扭。Java多好:默认情况下都是虚函数,允许被子类重写,但是对于有意不想让子类重写的方法用final关键字来修饰。
7. C#中new还可以用来指定子类的某个方法要隐藏父类的具有相同签名的方法。这是不是多余的?你不用也可以,不过csc.exe会警告你,如“lan.Other.Main(string[])”隐藏了继承的成员“lan.HelloWorld.Main(string[])”。如果是有意隐藏,请使用关键字 new。 像java那样默认多好啊。 但是话又说回来,C#这样做也是有原因的。如果类B继承了类A,B接下来有添加了一个方法叫做hi(),那是B特有的。然后类A(假设是别人来维护的,你不能看到源码)突然也增加了一个方法hi()。如果B自己那个hi()跟A那个hi()的返回值不一样,当你更新类库A后,可能导致程序运行错误或不能编译。C#就很好就地避免了这种问题。(虽然这种问题出现的概率挺小的…)
批注:其实这个还是和6有关,总之对于Javaer来说就是两个字“别扭”。那些非虚函数干脆就不允许改写就得了,像Java的final那样。干嘛“既要做婊子又要立牌坊”呀,当警告超过一定数量时,估计就掩埋了,不容易被注意到。而真等到了使用的时候,哪一个是多态?哪一个是“另起炉灶”?使用者不晕菜才怪呢!
8.C#中,防止一个类被继承,要用关键字sealed。而定义一个常量时,要用const。 像java统一用final多好啊。
批注:这倒没什么,关键字都一样了,显得人家MS多没水平吗。我们只是需要再多记住一些东西就是了,多无奈呀。
9.在C#中,要比较两个引用变量是否指向同一个对象,不能用java中的= =,而要用Object里的ReferenceEquals方法。C#中,不能用一个类的实例去调用该类的类方法,必须用类名。所以java中的o1= =o2等价于C#中的Object.ReferenceEquals(o1,o2)。
批注:都是操作符重载惹的祸。Equals就是Equals;ReferenceEquals就是ReferenceEquals。但 == 可要注意了,有的时候是 Equals 有的时候是 ReferenceEquals。== 被重载了,我反而更不敢用了,还是稍微费点事写 Equals 和 ReferenceEquals 吧,即不会犯错误,有意义清晰。
10.C#中没有原始类型的包装类,但是也提供自动装拆箱的功能,和java有的一样。区别是,C#的装箱是自动的,拆箱就要强制转换了。 int i=100; object obj=i; i=(int)obj; 具体怎么装和拆,我们不知道。只知道CLR将int转换成object了。
批注:包装类还是有的吧?如:int -> Int32;string -> String;甚至 object -> Object。是我的理解有误吗?至少从VS中关键字高亮的颜色就能区分开。
11.java的内部类有时候帮助很大。到了C#那,就只提供静态的内部类了。这意味着外部类只相当于是一个命名空间而已。C#中的内部类能访问外部类的私有成员,这可能会让它有点用。
批注:这一点我没什么研究,在Java中也是尽量不使用嵌套类。其实静态成员类+内部类(含:非静态成员类、匿名类、局部类)=嵌套类。如果要用也最好优先使用静态成员类,内部类最好少碰,尤其是匿名类(但有些地方还必须用它,矛盾呀)。
12.C#中虽然有运算符重载,但是为了整个.net的一致性,应该不会鼓励使用。因为有的.net语言没有运算符重载,而.net的一个目标就是消除各种语言的差别。
批注:用惯了Java的人想必也不会要这个“上天所赐”的。仅一个 == 就被MS自己重载成了9中的样子(其实,人家重载得还是很不错的,只是咱们在用的时候头脑不灵光)。你希望像 BigDecimal 这样的值类重载 + - * / 吗?又是 仁者见仁,智者见智了吧?
13.C#多了一个struct值类型,它就跟原始类型一样。微软在必要的时候会帮你将struct封装成Object,就像封装int类型一样。以至于你可以认为struct也是由Object继承而来,虽然struct本身并不支持继承。(struct可以不用new来初始化,但它里面的内容必须初始化后才能调用其方法;struct没有析构方法;struct没有默认的构造方法)。
批注:struct在C#中出现的原因我还真不敢乱猜,从C/C++沿袭而来?还是像MS说的在性能上略微优于class?总之,只要知道在构建值类的时候,可以使用之就可以了。
2007年11月2日 1.java中类的访问控制符只能是public,或者没有(即默认的包访问)。但是C#中,class和interface的访问控制符可以是public / private / internal / protected / internal protected。当然你必须先取得对类的访问,才可能访问到类的成员。
一个C#集合中可以包含多个public的类或接口,跟文件名没有关系。
批注:MS没有像Sun那样给namespace的命名方法一个官方的建议(Sun建议package的命名法为域名的逆序,均为小写字母)。而且.Net也不要求按目录及文件名保存类(Java最早也没有此要求)。哪种方式更好呢?我想还是一个习惯问题,至少我还是觉得Java的方式更清晰明了。而不少.Net的工程,打开后所有的Source文件都在一个“大平层”,很难受的说。
2.C#中的接口不能包含常量,而java可以。
批注:接口中应该/可以包括常量的定义吗?公说公有理,婆说婆有理。个人认为,即使Java运行,也尽量别这么做。
3.C#中的as和java中的instanceof功能一样。但C#提供一个据说是效率更高的as关键字。
批注:原作者笔误吧?是否应该是 is ? as 是强制类型转换,和更常见的 变量a = (类型)变量b; 不同的是,如果转换失败as会返回null,而括号式转换回抛出异常。as的语法和AS3语言中是相同的。
4.接口和抽象类在C#和java中都差不多,这里提一下接口设计和抽象类设计的区别之处。如果你更改了一个接口的设计,比如增加了一个方法,使用你以前的代码的用户将不得不改变他们的代码,否则不能运行和编译。但是如果是一个抽象类,你可以提供一个含默认实现的方法,用户的代码则不需要改变。
批注:这个事实在Java和C#中都是一样的。但是,就接口和抽象类(即使包括骨架类)的选用依据可不是这个,这只是一个表现而已。再有,接口一旦发布了,就是你对外的一种承诺。之后即使是版本升级也不能再做任何改动,哪怕是增加新方法。那非要增加怎么办?如果同时提供的骨架类也控制在你的手里,可以通过在这个骨架类(其实就是抽象类的一种用法,骨架类实现接口,实际类再继承这个骨架类,骨架类中可以为实际类实现一些通用的、或默认的方法)提供一份新增方法的默认实现来达到目的。但这并不是明智的,因为版本升级时需要增加的新方法,往往是一些实实在在的干活儿的方法,在骨架类中给出一个默认实现往往没什么实际意义。更好的做法,是写一个新的接口去继承原来的接口,把新增的方法在子接口中声明。这样可以保持100%向前兼容,需要实现新方法的类属于伴随此次接口升级或日后要取实现的类。
5.C#中一个类实现一个接口时,它的相关方法不必指明override;但一个类继承一个抽象类的抽象方法时,必须加上override,否则视为隐藏。(事实上,只有抽象方法或者是virtual、或者是接口方法才能被覆盖即override。不能无缘无故地override。)
批注:这个也没什么好说的,各家有各家的写法,如果非要说也还是习惯的问题。同上半篇的6。
6。C#中存在一个“多态起始点”的问题。如果一个类实现了接口的某个方法,只是接口到该类才有多态的功能,若要这种多态继承下去,该类必须指明是virtual,多态起始了,接下来的子类提供override就能多态了,不需要更多的virtual。
但是抽象类的抽象方法默认就是一个多态起始点,后续的子类只要override就行了。
批注:感觉还是同上半篇的6。也许是我还没深刻理解?
7.当一个类实现了两个接口,两个接口有一个相同的方法定义,C#有一种解决机制,叫做显示实现。Java干脆就不处理这种情况,反正实现之后就能调用了,不必指明是哪个接口的,留给程序员自己考虑。 当然C#中的显示实现还有其他功能。举个例子,接口A有一个方法叫做f(),类B实现了A。按理说B的实例就能自由调用f()了,但是如果有这样的要求:B的实例只有被cast成A之后才能调用f()。在java中,这样无理的要求是不允许的。但是C#可以做到,就是通过显示实现的方式。有谁会使用这样的特性?
批注:两个接口如果定义了相同的方法,方法名、参数个数、参数类型、返回值类型、可能抛出的异常(这个C#真没有)都一样的话,那实现它的时候,还区分是来自哪个接口的干吗?有这个必要吗?Java在这里“犯傻”我看挺好。
来源: <http://www.cnblogs.com/gc2013/archive/2014/08/12/3907813.html>