Why Java Sucks and C# Rocks（补1）：Reddit，兼谈C#属性
2010-06-28 14:18 by 老赵, 6732 visits最近博客冷清了不少，主要是事情较多，一是.NET交流会，二是工作，三是几篇暂时无法发在博客上的文章。周末在家，发现邮箱里经常收到SlideShare的邮件，说是我的Why Java Suck and C# Rocks幻灯片在推特上很火热。而今天早上我忽然发现，它被人发到Reddit的编程版块了，讨论地颇为热烈。关于讨论内容，您可以亲自阅读一下。最近的讨论也让我想要补充一些关于C#属性的问题。
关于这个话题，在我不断强调讨论的目的之后，在我的博客上还是有许多朋友没有明白我在说什么，热血上涌当即给予反击，这些从后面的评价中便可以看出。不过在Reddit上，当围观人群看到相同的内容，甚至只有幻灯片，没有更多解释说明，但是大家都能理解我的意思，都能意识到我是希望“用Scala代替Java语言”。而即便是没有看到幻灯片的最后，或是对此有不同意见，也都是在用正常的方式提出质疑。这样的差别让我感到很讽刺，有些话我已经说过很多次了，现在只是引一个例证，也就不再重复了。
在Reddit上的讨论中，有人提出C#里的属性和事件其实都只是方法的语法糖，意义不大。最近在一些人的文章里也出现了类似的说法。我在这个系列的中原本并不打算着重分析C#里的“属性”概念，因为它对于“编程思维”的影响可能并不如其他方面来的明显。不过如果真要深究的话，我还是非常看重这个语言特性的（不过其实属性和事件都是.NET特性）。那么现在我也来简单谈一下“属性”，而“事件”则在后面的文章里讨论吧——那篇文章的草稿已经躺了大半个月了。
属性，在C#里以get/set方法对的形式出现，例如：
// C# public class MyClass { private int m_count; public int Count { get { return this.m_count; } set { this.m_count = value; } } }
而在Java中的等价代码则是：
// Java public class MyClass { private int m_count; public int getCount() { return this.m_count; } public void setCount(int value) { this.m_count = value; } }
在Java中并非没有“属性”的概念，而是将它直接拆成了getXxx和setXxx两个方法而已，而对于一些工具（如IDE）、框架（如序列化框架）来说，它会忽略方法之前的get/set，直接将后面的字符识别为一种“成员字段”，而在.NET对象中，“属性”天生就是一种表示成员字段的标准方案。
在我看来，从使用上来说，属性比分离的方法要方便一些。例如我们要将MyClass对象的Count属性加1，则可以这么写：
// C#
c.Count++;
而在Java里则必须这样：
// Java
c.setCount(c.getCount() + 1);
当然您可能会觉得这方面的差距并不大。那么我们换一个场景，现在有一个User数组，我们要根据它的年龄进行排序：
// C# users.Sort(u => u.Age); // Java users.sort(#(User u)(u.getAge()));
这里我们暂且忽略Java中古怪的Lambda表达式写法，只关注“属性”和“get方法”之间的区别。在我看来，C#的代码体现了声明式编程的理念，从语义上讲可以清晰地视为“将u按u.Age字段”排序；与之想法，一旦我们只能利用getAge方法时，便又重新回到了“命令式”思维方式上。为什么这么说？因为调用getAge方法，意味着“获取”这个“Age”字段，它代表的是一个“动作”，表明排序时去“获取”这样一个数值，也就是体现了“怎么做（how to do）”，而不像C#代码中体现的是“做什么（what to do）”。
下面一个例子可能更为典型。例如在使用ORM框架，如(N)Hibernate时，我们时常会在复杂的XML配置中迷失方向。后来有了Fluent NHibernate，让我们可以使用“代码”来进行配置，这样无论是从可读性还是可维护性来说都有了质的飞跃。目前在项目中，由于没有使用关系型数据库，于是我便遵循Fluent Interface的理念，设计了这样的API：
Property(c => c.ArticleID).Identity();
Property(c => c.Content).Name("Html");
Property(c => c.Tags);
Property(c => c.Keywords).ChangeWith(c => c.Content).ChangeWith(c => c.Tags);
以上代码是Article对象的映射规则，四行代码表明：
- 将ArticleID映射为标识符
- 将Content映射为存储中的Html字段。
- 将Tags映射至存储，名称不变。
- 将Keywords字段映射至存储中，并随Content及Tags字段改变。
我写的映射框架支持传统ORM框架的状态跟踪功能，不过还提供了只读字段的“按需改变”。如Keywords，它是只读属性，框架会读取它的值，并将其放入存储内（以便进行查询），但是我们不需要将其写回对象中去。同时，在Contents和Tags改变的时候，框架也会重新获取Keywords的值，并跟新至存储内。利用C#的表达式树特性，我们可以十分轻松愉快地“声明”出这样的规则。在这个规则中，我们利用“属性”来标明字段之间的关系，这可以说是一种DSL。但如果没有属性，一切都是get方法，那么这段代码又会是什么样子呢？
所以，相对C#来说Java语言中很难写出优雅的声明式代码及Fluent NHibernate这样的框架。原因有多种，如Lambda的古怪语法形式是为一、缺少表达式树功能是为二，而不直接支持“属性”这样的概念也是另一个原因吧。
沙发，终于抢上了，