关于"非可变类"的讨论

Effective Java中 第13条: 支持非可变类

 

这里对非可变类模式有很详细的讨论, 我个人是该模式的坚决支持者, 经过我手的东西我也都在实践这一点, 然而今天发现了一个关于非可变类的一个小插曲(应该还不算是麻烦 *_*).

 

说的这个"非可变类", 其实是java中的int类型(让我们叫他非可变的东西吧), 是他带给了我们这个故事.

 

同事和我有一个需求:

有三个int, 要将其中最小的一个值, 赋值为第二小的减一, 第二小的赋值为最大的减一.

注意, 不是取他们的最大值异或最小值,并将这个最大值或最小值减一.

因为后续还要用到这些a,b,c

也就是说我们改变一些东西的同时, 还要部分依赖于他们以前的一些信息(比如位置或次序)

 

这确实是我们不常做的一个事情,所以我们的第一反应是, 设计上的什么问题, 导致了这个蹩脚的需求.

但是我们还不能一下子把这个问题说出来.  对此, 我同事的观点是, 先别管设计.

理由是:"毕竟, 这不是一个复杂的功能, 先把它实现出来.  否则很丢人 ^-^"

 

我很认同, 于是我们开始了...

我们先考虑, 怎么把这个东西, 写的具有写美感,

显然一大堆if是可以办到的, 但是有些丑陋, 而且, 一旦增加到4个或n个数的时候, 我们的代码就会失效.

 

最后我们使用了下面的算法.

写道

step01 : 创建一个数组, 存放这些数值, 并对其进行排序

step02 : 对每一个int, 赋值等于数组中刚好比他大的那个值减一, 没有比他大的,则该int保持不变.

排序是为了利用现有的api, 关键是Step02.

 

解决问题之后, 我们的反思是.

我们有一组相同的东西, 他们要变化, 因此我们要把们放到数组或者容器中进行管理.

像这样没有使用集合类, 而孤立的使用了一组非可变类的时候,我们不应该"在改变他们的同时, 还依赖他们以前的值".

或者干脆都按照不可变类的方式使用它们更好.

 

恩, 由此看来, 这个小插曲确实不能作为非可变类给我们带来的麻烦,

(ps.一定会有这样的声音, 类不可变了, 在某些场合,会给我们带来麻烦, 对这种声音的回答我想应该是: 当感到蹩脚的时候, 首先想想是不是设计上面出了问题.)

 

非可变类在损失了一部分类似C/C++的灵活性的同时,给我们带来了更多的好处:

参:Effective Java中 第13条: 支持非可变类

我本想附上这一条的链接, 但遗憾网上没有找到相应的资源.

 

另附Object Mentor上的一篇blog:

A Wish List for the Next Mainstream Programming Language

评论

2 楼 unsid 2009-01-14  

如果非API设计很少考虑这个问题吧,在设计API的事情确实是个比较重要的问题

1 楼 wjason 2009-01-14  

工作上的一点整理, 希望与大家讨论, 指出不足.