4 C#和Java 的比较

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在这里“犯傻”我看挺好。