|
优秀得太多了
1:空值判断
在Java里面null是不能作比较的(==null除外),例如下面代码在Java里面会抛异常,在C#里类似的代码能正常运行
Integer i=null;
if(i==1){}
if(1==i){}
switch(i){}所以Java里面每次使用if或者swich之前,最好先判断一下里面的变量是不是空值, 而写C#代码就没有这种顾虑。
2:字符串相等判断
在Java里面不能使用==判断两个字符串是否相等,要使用equals方法,但不要以为把==改成equals方法就完事了,还要考虑空值问题,例如以下代码很明显因为调用equals的对象是null会抛异常
String s=null;
s.equals("");在C#里面就没有这种顾虑了,==两头哪边是空值都没问题。但在Java里面int这些基础类型又可以使用==判断是否相等,因为Java不支持操作符重载,你想搞得String也统一使用==判断是否相等是不可能。但回过头来,判断一个字符串是不是null又不能用equals,又得用上==了。
Java的这个字符串判断方式连第三方组件都看不过眼,在jsp和MyBatisd的xml文件里面,都支持使用==判断两个字符串是否相等。
我做事比较粗心大意,总有忘记了要用equals,写成==的时候,导致相关代码总返回false。
3:失败的泛型设计
Java的泛型我现在还没有驾驭它的能力,我曾经试过通过泛型去定义一个把传入的Map转换成目标类型对象的方法:
public T ConvertMpToObject<T>(Map map)
{
return null;
}就这样在C#看起来很平常的方法,在Java里面无法通过语法检测,编译不起来,真是连TypeScript都不如啊。
后来我还了解到,Java的泛型还有一个“类型刷除”的特性,无法在运行时获取泛型的类型,也就是说上面方法就算能通过编译也没有用,如果不增加额外的参数,则无法获取T的类型来创建新对象。
其实Java那个泛型我估计它自己都没有完全搞明白,举个例子:
Map<Integer,Integer> map=new HashMap<>();
int value=map.get(&#34;abc&#34;);这段代码d中的&#34;abc&#34;类型没有对上定义变量map时限定的Integer,但居然可以编译通过!
对应的C#代码是不可能通过编译的:
Dictionary<int,int> dictionary=new Dictionary<int,int>();
int value=dictionary[&#34;abc&#34;];
error CS1503: Argument `#1&#39; cannot convert `string&#39; expression to type `int&#39;
Java的失败的泛型设计在整个框架里面随处可见,举个例子Java里面有个List<String>类型的对象list,要转换数组的话调用list.toArray()返回的居然是Object[]而不是Stirng[],要返回Stirng[]居然要写成list.toArray(new String[0])。这样的诡异特性在其他泛型相关的类里面也存在,而且还推陈出新,stream api里面,toArray、toList又换了另一种玩法。
另外Java的泛型还不能使用基础类型,例如不能定义List<int>要改成List<Integer>。
4:过度设计的枚举enum
在C#里面enum的实际值是一个整数,在Java里面enum值被扩展成自身的类对象,这样Java的enum就比C#强大多了,跟类一样,可以随意在enum里面定义构造函数和方法,但不允许继承。
但不知道是不是因为不能直接转换成整数,Java的ORM(MyBatis)内置转换器都不支持enum类型映射成整数类型(但映射成VarChar可以),我接触的Java程序员也很少用enum,在需要用到enum的地方都会用常量代替。
5:没有属性property
Java在语法层面没有property特性,但很多第三方组件都会把类似以下的变量定义和get/set方法的组合解释成属性。
/**
*姓名
*/
private String name;
public String getName(){return this.name}
public void setName(String name){this.name=name}显然C#对应的最简化写法public string Name{get;set;}要简单很多。
也许很多人会觉得C#的property只是个语法糖,在Java的IDE里面按个快捷键一键生成get/set方法也跟C#定义一个属性一样快。但我后来发现发现了写法以外的一些问题,例如跟上面的代码一样,Java程序员都习惯把属性的注释写到一个private变量上面,这样我在外部调用get/set方法的时候是无法直接看到这个注释的。
另外,一些针对属性的注解(C#叫Attribute)在Java里面也比较混乱,有些(例如@TableField)是放在变量上的,有些(例如@JsonIgnore)是放在get/set方法上的,这都是没有property引发歧义。
然后,有些操作符应为没有property特性而不能使用,例如C#上面的 item.Names+=&#34;、&#34;,如果Names是个property,那么在Java里面就只能写成 item.setNames(item.getNames()+&#34;、&#34;)。
另一方面,Java在boolean的property命名规范上有个坑
boolean类型set、get方法 - 山水花草 - 博客园
更荒唐的是,不同框架(例如fastjson和gson)对这个坑有不同的解读
解析对象时,把字段名改了,bool类型的变量名前面的is自动去掉了
小灰:为什么阿里巴巴禁止开发人员使用 “isSuccess” 作为变量名?
大多数Java程序员为了避开这个坑,不使用boolean类型,而使用Integer。
6:难用的日期时间类型
不像C#那样只有一个日期类型DateTime,在Java8之前,Java有Date、Calendar和TimeStamp这3种日期类型。3种时间类型的区别在于精度不同,精确到秒、毫秒还是纳秒。
在低版本的Java中,Date的用法跟JavaScript的Date差不多,主要是构造函数Date(int year, int month, int date),和getYear()、getMonth()、getDate()……这些方法,但getYear()和getMonth()都很诡异,getYear()返回的是和1900相减的结果,getMonth()返回的月份是从0开始的。
后来不知道是不是因为冒犯了Java的哪条设计原则,上面的方法都被 @Deprecate 注解了。想要通过年月日构建Date对象或者获取Date对象的年月日部分得用上辅助类。
因为原生的不好用,强大的Java第3方来救场了,推出了一个叫Joda Time的日期时间处理类库,不过我也只是听说过,公司里面没见人用。
到了Java 8官方又推出了一套新的java.time的api,欲以用LocalDate代替原来的Date类型,不过感觉第3方对这个东西不是很买账,MyBatis还没有直接支持LocalDate类型的映射。
另外一面Java官方也没有类似C#的TimeSpan时间计算类型。
7:Array和List没有共同基类
在C#里,如果想自定义一个既支持数组,又支持List和其它集合类型的方法,只需要把方法的参数类型定义为IEnumerable类型就可以。
但在Java里,Array和List没有共同的基类(Object除外),也没有实现共同的接口,不能这样搞。
所以大部分Java程序员都使用List而不使用Array类型。
8:先天不足的Java类库(stream api)
很多人觉得C#比Java好用是因为C#有后发优势,作为后来者填平了Java踩下的坑。但我觉得不完全是这样,上面说的LocalDate就是一个活生生的例子,比起C#的DateTime晚了10多年出现,但又不比C#的DateTime好用。
另一个活生生的例子就是Java 8推出的stream api,C#里面与之对应的应该就是2008年发布的Linq。我粗略比较了一下,stream api里面对比Linq缺少的方法有OrderByDescending、SkipWhile、Average、Last、Union、Zip、Join、GroupBy、GroupJoin、Intersect。
也许因为Java里面缺少匿名类型和扩展方法两个语言特性,上面提及的Join以及后面的方法在Java里面是不可能实现的。但为什么这次Java作为后来者,不把C#优秀的语言特性搬过来?在我看来这确实是匪夷所思。而且这个api的名字为什么叫stream?单从名字来看看不出和Linq有什么联系的,还以为是一个流处理的类库。
因为Java的先天不足,实现相同功能的类库,总觉得都是C#的好用,例如C#方面http://Json.NET(正名叫Newtonsoft.Json)、HtmlAgilityPack、DotNetZip、Aspose这些常用类库,虽然Java也有实现相同功能的类库,但总觉得C#的用起来要爽。而且这种先天不足也不是后天能够补救的,就算是大公司Goolge搞出来的Gson也没有小公司做出来的http://Json.NET用起来爽。 |
|