哲学上说变与不变,讲的是绝对运动与相对静止的道理,在代码设计中,也有许多变和不变之间的辩证故事。
有一些类在创建以后,整个生命周期内都不会发生变化,这种模式被称为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.
文章系本人原创,转载请注明作者和出处