瓜娃之走马观花 (1) - List和Map

序

花开花落，花落花开。少年子弟江湖老，红颜少女的儿子都会打酱油反三俗了.

蓦然回首, 那个仿佛刚刚还在上幼儿园, 拉着我的手让我带着到麦当劳买鸡块冰激凌吃的小屁孩儿; 上了小学, 抱着我给买的盗版commando苦苦钻研攻略的小表弟, 开始写java程序了!

暑假去小表弟学校宿舍晃了一下. 书桌上随手堆着的可乐矿泉水瓶; 书桌下凌乱的鞋子, 鼠标; 寝室门上的个性标语; 隔壁在炎夏里半裸着看片子(木有看清是女主是否半裸)的猥琐男生, 都让俺情不自禁地小资起来: 唉, 世界是你们的了!

唯一地遗憾是没有重温一下女生寝室的风光 --- 上了年纪了, jailbreak门口大妈的身手不再了呀!

小兄弟是个努力的好童鞋. 于是咱自然当仁不让开始介绍UML, SOA, 4GL, J2EE, Agile Programming, JSR168X --- 噢, 不好意思, 又不小心yy了, 俺是粗淫, 这些说实话不懂地.

咳嗽, 是介绍JUnit, TDD, 和瓜娃 --- 就是Google Collection的重装上阵: Guava.


一. Lists和Maps

介绍瓜娃主要是觉得它是个老老实实的能帮助写代码的工具库. 不用把它当作正儿八经的什么东西学习 (说实话, 那里面的东西俺估计也就接触过两成了不起了), 把那个jar文件放到你的classpath里, 然后哪怕你就知道一个库函数呢, 对景的时候也是个帮手啊.

比如, 最简单地, 用java5以上的话(2010年了, 还在用上古神器jdk1.3或者1.4的首长请举手. 敬礼! 首长辛苦了!), 你怎么new一个ArrayList呢? 这样吧?

List<String> list = new ArrayList<String>();

怎么new一个HashMap呢? 是不是这样?

Map<String, Integer> map = new HashMap<String, Integer>();

对俺们这些用惯了瓜娃的懒人, 写那个<>里面的东东两次就觉得累得慌, 除非一些特殊的场合不想依赖瓜娃的jar文件的, 俺们一般都改写成:

List<String> list = Lists.newArrayList();

Map<String, Integer> list = Maps.newHashMap();

Lists和Maps是两个工具类, Lists.newArrayList()其实和new ArrayList()几乎一模一样, 唯一它帮你做的(其实是javac帮你做的), 就是自动推导(不是"倒")尖括号里的那坨叉叉.

这两个东西要说技术含量, 附加价值差不多趋近于0. 但是越是这种简单的不用脑子的东西, 越是让人惊讶地有邪异的吸引力. 我就看过好几个人说, 他们使用瓜娃的主要目的, 就是newArrayList()和newHashMap(). 毕竟, 这东西每个人每时每刻差不多都要用到吧?

当然, 瓜娃提供的远不止这两毛五, 买一根小豆冰棍儿都不够. 比如, 除了new一个空的ArrayList, 你还想往里放点数据. 直接用jdk的话, 大概是这样:

List<Integer> list = new ArrayList<Integer>();
list.add(1);
list.add(2);
list.add(3);

用Lists是这样:

List<Integer> list = Lists.newArrayList(1, 2, 3);

嗯, 是不是有点意思了? 值一个"可爱多"了吧?


二. ImmutableList和ImmutableMap

现在主流java社区倾向于同意, immutable对象(就是说状态不变)是个好东西. 它能让程序逻辑变得简单易懂, 而且减少出错的可能性.

JDK目前不提供immutable集合. 瓜娃提供的最主要的immutable集合, 是ImmutableList, ImmutableSet和ImmutableMap.
顾名思义, 一旦你创建了一个ImmutableList或者ImmutableMap, 你就再也不能改变它了. 它就像你记忆中初恋的那个她, 不管时光荏苒, 沧海桑田, 永远年轻美丽语笑嫣然 --- 当然, 前提是你还活着.

那么怎么创建ImmutableList呢? 嗯, 除非语言直接提供支持, 这应该是最简单的方式了:

ImmutableList<Integer> list = ImmutableList.of(1, 2, 3);

ImmutableMap一样简单:

ImmutableMap<String, Integer> map = ImmutableMap.of(
    "1", 1,
    "2", 2,
    "3", 3
);

对比一下用HashMap的情况:

Map<String, Integer> map = new HashMap<String, Integer>();
map.put("1", 1);
map.put("2", 2);
map.put("3", 3);

还是前者舒服吧?

那么, 假设你所有的不是事先知道的一些常量. 比如说, 你要从一个数据库里读出一些基本信息保存在内存里. 用of()就不好使了, 这时候, 可以用builder模式:

ImmutableMap.Builder<String, Integer> builder = ImmutableMap.builder();
for (...) {
  builder.put(name, age);
}
ImmutableMap<String, Integer> map = builder.build();

ImmutableList和ImmutableMap最常用的就是创建一些集合常量 (这些常量都是static final的).

另外一个主要的用途, 是作为其它Immutable对象内部使用的数据结构.


三. 讨论

一个也许会存在争议, 但是瓜娃开发组强烈推荐的使用方法, 是凡是可能的情况下, 给你的函数的返回类型用ImmutableList和ImmutableMap, 而不是它们实现的接口: List和Map. 比如:

ImmutableList<String> getNames();
ImmutableMap<String, Integer> getAgeMap();

而不是:

List<String> getNames();
Map<String, Integer> getAgeMap();

为什么这样呢? 这是因为immutable集合是一类特殊集合, 它们不象ArrayList, HashMap那样是纯粹的实现细节, 相反, 这些类型携带了重要的语义信息: 它们是不可变的.

如果调用者使用了list.add()或者map.put(), 得到的将是UnsupportedOperationException异常.

通过返回ImmutableMap和ImmutableList, 函数签名清楚地告诉调用者什么可以做, 什么不可以做. 这对大型程序中团队协作, 代码理解和维护好处多多.

实际上, 最有争议的, 是在jdk的集合框架设计上. Sun把List和Map的接口设计为mutable(可变的), 但是同时允许实现类不实现某些函数, 比如add(), put(). 一些貌似爱思考地程序员(包括俺)就想啦: 为啥你不干脆把写操作分离出来呢? 这样当一个人拿到ImmutableList的时候, 他根本就没有add()可以调用, 更甭说运行时抛异常了?

Sun对此专门有个回答. 是否信服就由你了. 不过不管喜不喜欢, 我们今天所有的就是这个设计: 一个List可能是可变的也可能是不可变的. 大概还是不要钻牛角尖, 入乡随俗吧.

未完待续