关于"非可变类"的讨论
Effective Java中 第13条: 支持非可变类
?
这里对非可变类模式有很详细的讨论, 我个人是该模式的坚决支持者, 经过我手的东西我也都在实践这一点, 然而今天发现了一个关于非可变类的一个小插曲(应该还不算是麻烦 *_*).
?
说的这个"非可变类", 其实是java中的int类型(让我们叫他非可变的东西吧), 是他带给了我们这个故事.
?
同事和我有一个需求:
有三个int, 要将其中最小的一个值, 赋值为第二小的减一, 第二小的赋值为最大的减一.
注意, 不是取他们的最大值异或最小值,并将这个最大值或最小值减一.
因为后续还要用到这些a,b,c
也就是说我们改变一些东西的同时, 还要部分依赖于他们以前的一些信息(比如位置或次序)
?
这确实是我们不常做的一个事情,所以我们的第一反应是, 设计上的什么问题, 导致了这个蹩脚的需求.
但是我们还不能一下子把这个问题说出来.? 对此, 我同事的观点是, 先别管设计.
理由是:"毕竟, 这不是一个复杂的功能, 先把它实现出来.? 否则很丢人 ^-^"
?
我很认同, 于是我们开始了...
我们先考虑, 怎么把这个东西, 写的具有写美感,
显然一大堆if是可以办到的, 但是有些丑陋, 而且, 一旦增加到4个或n个数的时候, 我们的代码就会失效.
?
最后我们使用了下面的算法.
写道step01 : 创建一个数组, 存放这些数值, 并对其进行排序排序是为了利用现有的api, 关键是Step02.
?
解决问题之后, 我们的反思是.
我们有一组相同的东西, 他们要变化, 因此我们要把们放到数组或者容器中进行管理.
像这样没有使用集合类, 而孤立的使用了一组非可变类的时候,我们不应该"在改变他们的同时, 还依赖他们以前的值".
或者干脆都按照不可变类的方式使用它们更好.
?
恩, 由此看来, 这个小插曲确实不能作为非可变类给我们带来的麻烦,
(ps.一定会有这样的声音, 类不可变了, 在某些场合,会给我们带来麻烦, 对这种声音的回答我想应该是: 当感到蹩脚的时候, 首先想想是不是设计上面出了问题.)
?
非可变类在损失了一部分类似C/C++的灵活性的同时,给我们带来了更多的好处:
参:Effective Java中 第13条: 支持非可变类
我本想附上这一条的链接, 但遗憾网上没有找到相应的资源.
?
另附Object Mentor上的一篇blog:
A Wish List for the Next Mainstream Programming Language
1 楼 wjason 2009-01-14 工作上的一点整理, 希望与大家讨论, 指出不足. 2 楼 unsid 2009-01-14 如果非API设计很少考虑这个问题吧,在设计API的事情确实是个比较重要的问题