哲学上说变与不变，讲的是绝对运动与相对静止的道理，在代码设计中，也有许多变和不变之间的辩证故事。

有一些类在创建以后，整个生命周期内都不会发生变化，这种模式被称为Immutable Pattern。

较弱的不变模式：指的是一个类的实例状态是不可变化的，但是这个类的引用的实例却可以变化。

比如说：Visitor模式常常是这样的，整个流程是不可变的，但是我为我的整个流程提供灵活的切入点，提供出来访问接口，供变化的部分完成。

较强的不变模式：一个类实例状态不可变，其内部引用的所有实例也不可变。

这个就比较多了，JDK中的String、Integer、Byte等都是不可变的。

变化的场景需要考虑许多事情，因为变化带来了“状态”的概念。但正因为有了状态，整个世界才丰富多彩。变化需要考虑共享访问的情形，需要考虑状态之间的关系。当我们享受到代码变化带来的愉悦，也开始追求不变的代码，那一份古朴和单纯。

不变，引伸出对象复用的好处来。无状态的单例，很多场景下可以看作简单的工具类；更多的对象在一定时期内无状态，比如Prototype模式，比如线程池、缓存，这些都将哲学中的变与不变最终结合到代码中去。不变，是快速的、简单的、敏捷的，将变化的状态连结起来了。

程序=算法+数据，算法是不变的，数据是可变的。仿佛从软件的一开始，变与不变就给后续的万事万物埋下了伏笔，代码的世界围着这个特殊的视角旋转。随着动态语言的兴盛，以往不可变的方法也可以被改变，方法本身也能变成对象，数据和算法轻而易举地在代码中变幻，我们越来越疑惑，还有什么不变的东西，可以让我们彻底看清和相信一次？

Action是具备状态的，线程独立的；Service和DAO是无状态的，是可以被池化的。不变得再极致一点，我希望从编译之后它就是不变的，而不是对象创建之后不变，这就是方法。静态语言中的方法逻辑本身就是不可变的；而另一方面，当方法内部所使用的一切变量，都严格被控制在方法内部的临时变量或者按值传递的参数中，这说的，不正是函数式编程吗？

也许，其实软件的本质很简单，我一直在思考，软件复杂化的本质就是为了追求简单的东西。就像这个变化莫测的世界，不变的故事，总是那么淅淅沥沥的，却又惊人地相似。

本文的最后，Rod Johnson说：

If possible, design applications to use a stateless service layer. Hold state in the web tier, rather than in the business logic tier, if possible.