不变性immutablity设计
不可变性是一种抽象，它并不在自然界中存在，世界是可变的，持续不断变化。所以数据结构是可变的，他们是描述真实世界某段时间内的状态。而状态经常会被修改，如下面情况：
1.状态被并发线程同时修改
2.多个用户对一个共享对象(状态)进行冲突性修改。
3.用户提供了无效数据，应该被回滚。
在自然可变的模型下，会在上面情况下发生不一致性或数据破碎crushing，显然可变性很容易导致错误。我们需要的是一种新视野，新角度，一种事务transaction视野，当你从事务性程序中看世界时，一切都是不可变的。这和蒯因与引用透明 中功能重复执行不可变原理非常类似，体现逻辑的线性特征。
不可变性说得这么玄，是不是和平常编程没有太大关系呢？
完全错误。举个例子，当你要对一个变量进行修改时，这个变量处于一个对象A内，你是直接对这个对象(A类的实例)内这个变量进行修改？还是重新创建一个A类新的对象实例，新的变量在新的对象实例中，然后替换掉原来的对象呢？
很多程序员对这么一个权衡问题没有过多考虑，基本是随意选择其中方案，甚至根据工作量多少为抉择，这些不经意行为都为整个系统的性能留下祸根。
这个问题其实涉及到了不可变性的问题，如果A类被设计为不可变了，那么就要采取第二个的方案，创建后替换，这个答案带来两个问题：
1.程序员如何知道A类是一个不可变的类？
2.不可变类为什么能够获得性能提高？
关键问题是第一个，我认为我们可以通过OOA/OOD等建模方式明确哪个类为不可变，很显然DDD领域驱动设计方法中，有值对象为不可变的概念，如果领域专家指定来自需求中哪个类是值对象，那么我们程序员就容易在编程实践中采取构建替换的办法，从而又能照顾到了计算机底层的性能。
我2006年在jivejdon按照DDD设计开发时，探索性地提出状态可以表达设计为值对象概念，见实战DDD(Domain-Driven Design领域驱动设计:Evans DDD)，虽然此后一直有反复和怀疑，但是最近看了如何打败CAP定理？一文以后，比较肯定了自己当初想法，心中一块石头落地，这是一种探索的乐趣。
下面谈谈我如何在JiveJdon 4.5版本中如何把值对象状态不可变性贯彻落实完整的情况，在之前版本因为心中不确定，所以对状态修改时，没有遵循上面提到的第二步法则，而是直接对对象字段修改，就好象直接去修改数据表字段那样鲁莽。
这种破坏性修改的恶果也让我吃尽苦头，就是数据出现严重的不一致性，如帖子更新状态，经常是增加新帖后，在论坛列表的“最近更新”栏目出现的不是最后增加的那个新帖，有时正确有时错误，头疼不已，当时是非常怀念基于数据库的编程模式，因为这个功能只要通过一条SQL查询就能完成，轻松而简单，而JiveJdon是基于内存中的对象，这个功能是对对象的状态进行修改完成的，方式不同，思路就不一样了，后来虽然费了九牛二虎之力勉强正确，但是不够优雅和轻量，一直是自己不敢面对的痛。
现在理顺了值对象状态不可变性这样一个思路，我几乎三下五除二把JiveJdon这个功能就重构了，而且一次性调试通过。下面谈谈这个重构过程。先展示一下JiveJdon的设计类图：
将ForumThreadState这个经常变换的状态和实体聚合边界内其他变化是不一致的，惨遭DDD一书中的订单价格变化案例设计为单独的ForumThreadState，下面问题是，ForumThreadState变化是直接修改其中字段，还是重新构建一个ForumThreadState替换原来的，不幸的是我和大多数一样，起初没有太多留意走的是前一种办法，绕了不少弯路。
[该贴被banq于2011-10-21 08:45修改过]
将ForumState以Java中最大可能的不可变语法表达，在国外论坛上看到不少Scala程序员欢快地使用Scala的不可变+Actor两个方式编写出简单容易并发程序，我也可以借助JdonFramework的ES模型，通过稍微复杂点的不可变+Domain Events实现类似的并发编程，ForumState的稍微复杂点不可变性的代码如下：
public class ForumState {
private final AtomicLong threadCount;
private final AtomicLong messageCount;
private final ForumMessage lastPost;
private final Forum forum;
private final SubscribedState subscribedState;
public ForumState(Forum forum, ForumMessage lastPost, long messageCount, long threadCount) {
super();
this.forum = forum;
this.lastPost = lastPost;
this.messageCount = new AtomicLong(messageCount);
this.threadCount = new AtomicLong(threadCount);
this.subscribedState = new SubscribedState(new ForumSubscribed(forum));
}
<p class="indent">
|
源码见：
http://code.google.com/p/jivejdon/source/browse/trunk/jivejdon/src/com/jdon/jivejdon/model/ForumState.java
Java中体现不可变性的特点主要是final和构造函数，ForumState的就没有了所有setXXXX方法，不能对ForumState内部单独修改，强迫替换整个对象。
有了不可变性的值对象，根据DDD设计要则，还需要一个工厂来维护这种不变性，也就是ForumState的创新new需要通过工厂专门统一实现，不是任意地随意new创建的，
专门创建一个FormStateFactory负责FormState的生命周期维护，FormStateFactory代码:
public interface ForumThreadStateFactory {
void init(ForumThread forumThread, ForumMessage lastPost);
void addNewMessage(ForumThread forumThread, ForumMessage newLastPost);
void updateMessage(ForumThread forumThread, ForumMessage forumMessage);
}
<p class="indent">
|
http://code.google.com/p/jivejdon/source/browse/trunk/jivejdon/src/com/jdon/jivejdon/model/state/ForumThreadStateFactory.java
那么现在来回答上面我提出不可变性编程中第二个问题，不可变性为什么可以获得性能提升呢？
主要是回避了共享锁synchronize，原来在上面的addNewMessage和updateMessage方法前都要加同步锁synchronized的，现在不需要了，因为新对象替换旧对象本身是一个原子操作。对比图见附件图。
在多线程编程中有一个不可变Immutable模式：
Immutable是当被构造以后就不再改变。
Immutable 的对象总是线程安全。
特征：
1. 构造以后就不会改变;
2. 所有字段是 final;
3. 它是正常构造。
发布一个Immutable对象是线程安全的。
猜你喜欢