不可变

设计模式一个基本点两个原则：一个基本点是找到变化、封装变化；两个原则是基于接口而不是基于实现、组合优于继承。核心是可变与不可变的隔离、解耦。 核心：找到变化，封装变化 找到变化，封装变化。 易变与不易变的隔离，可变与不可变的隔离，稳定与不稳定的隔离。 设计模式一个基本点两个原则： 一个基本点：find what varies and then encapsulate it。找到变化、封装变化； 两个原则：基于接口，而不是基于实现；组合优于继承。 找到变化、封装变化：核心是可变与不可变的隔离、解耦。开闭原则也有这个思想。 所有的扩展性都是因为变化，分解可变与不可变作为一个基本点，没毛病。 基于接口，其实目的也是为了组合 基于接口，其实本质也是为了解耦可变与稳定，接口应该是稳定的，实现是易变的。 组合优于继承，因为继承是紧耦合的。 组合更利于可变，组合的前提是抽出来不可变的接口，即封装可变与不可变。 接口和组合，其实都是可变与不可变的实践。 通过不可变的组合实现可变。 一个例子：iaas 的调度方案 存储组，会选一个默认存储池，它会影响调度结果，所以这个也应该做到调度里。 这是一个很容易进入误区的陷阱。 实际上上层很多东西都会影响到底层呀，因为底层接收的是参数，上层参数变了，底层结果当然也会变。这不能作为划分边界的依据呀。 比如调解手机声音，不能说，腾讯音乐能调整，所以我要把腾讯音乐做到手机的扬声器模块。 我们调度，肯定是一个原子调度模块，我们提供参数，上层传参，控制调度结果。 我们提供各种单一的原子的能力，上层通过组合这些原子能力实现多样化可扩展的调度。 比如选择存储池，底层原子接口只接受存储池参数，不应该帮去改变或者帮他去选择。这是单一的原子的。如果加了选择的逻辑，就不单一了呀。 同时，底层应该是不易变的。 自动选择就是一个易变的逻辑，不同客户需求不同。但是根据存储池调度，这个是稳定的。 所以，我们只需要接受存储池参数即可。至于这个参数怎么玩出花，是上层的事。 所以存储组交给上层服务是 ok 的。 分层，哪些是产品层，哪些是应用层，哪些是基础层，边界。 基础层必然是稳定的、原子的、提供基础能力，这就是边界。 小结 找到变化，封装变化； 设计模式一个基本点两个原则：找到变化封装变化、基于接口而非实现、组合优于继承； 核心是可变与不可变的隔离、解耦； 接口应该是稳定的，实现是易变的； 通过不可变的组合实现可变； 基础层必然是稳定的、原子的、提供基础能力，这就是边界。