瓜娃之蜻蜓点水 (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多是可变的也多是不可变的. 大概仍是不要钻牛角尖, 入乡随俗吧. 未完待续