关于 Immutable Object 模式适用场景的探讨

什么是 Immutable Object

Immutable Object 模式是一种将对象设计为一旦建立就不能修改其属性值，全部的属性值都只有 getter 方法没有 setter 方法的模式。

该模式有两种实现途径：一是在构造方法中提供全部属性的参数，设置好全部的属性值；二是提供 builder 方法来让用户逐步设置属性值，最后再建立对象实例。前者的好处是代码量较少，后者的好处是方便用户自由选择给哪些属性赋值。

Immutable Object 的优势

一个不能修改属性值的对象有什么优势呢？首先它是线程安全的，并且多个线程对它的访问不须要有任何同步操做，所以不会对线程的运行效率产生任何影响。

其次是在某些场景下，使用 Immutable Object 这种保守的封装方式能避免一些问题的发生。

举个例子，HttpClient 经过配置对象来进行初始化，而这个配置对象是调用者给过来的，这意味着调用者可能会继续持有该对象，甚至在 HttpClient 的运行过程当中还会试图修改配置对象的属性。

这么作是存在比较严重的问题的。首先，这些修改有多是无效的，由于一旦完成初始化，配置对象中的一些属性就不会再用到了；其次，有些修改可能会致使并发问题，由于配置对象是会被多线程访问的；再次，只有初始化过程会对配置属性进行检查，若是一个属性在这以后被修改为了一个无效的值，这会致使故障的发生。

因此，将配置对象设计为 Immutable Object，就能避免上面所说的问题，极大的提升应用的健壮性。

避免滥用 Immutable Object

但若是一个对象不存在上面所说的使用场景，那么就不须要将其设计为 Immutable Object。典型的例子就是 DTO 对象，这类对象的职责仅仅是传递数据，其生命周期很短，甚至在方法执行完后就立刻失去任何引用，能够被回收了。

对 DTO 对象的属性进行修改不会引起任何问题。由于做为传递对象，发送方只会写，接收方只会读，并不须要作特别的限制。

更重要的是，DTO 对象是必定有序列化和反序列化的要求的，这是它的一个自然职责，Immutable Object 由于缺乏 setter 方法，会让全部依赖 setter 方法进行反序列化的框架没法正常运做。因此 Immutable Object 不适合用在 DTO 类上。

总之，咱们在对一个类应用特别的设计模式时，最好先考虑清楚这个设计模式的目的和适用场景，这个类是否符合这个场景。