程序代码进化的一些思考 ： 从面向对象到设计模式，到函数式编程

最初面向对象是为了保持状态的针对性:

Class P { 状态a, 状态b，状态c, 状态d，状态e，状态f, ... }

P的方法:

fun1{操作a b}

fun2{操作a b c}

fun3{操作d}

fun4{操作e f}

...

在面向对象使用久了之后，开发者们必定为庞大的状态数量和方法数量而吓退，

从而怀疑起面向对象的可用性。

于是， 设计模式，在反复的推导实践中，被提炼出来用于简化问题:

Class P { 状态a, 状态b，状态c }

Class M { 状态d }

Class N { 状态e，状态f }

P的方法:

fun1{操作a b}

fun2{操作a b c}

fun3{通过M操作d}

fun4{通过N操作e f}

P的状态和方法被委托到与d e f联系更紧密的M N对象中操作.

开发者关心的是P M N的通信， 而不是P的一大堆方法的逻辑.

无论是对描述，还是思考设计，都是一种质的提升.

在函数式鼓吹现代化改革中，辩证的思考函数式所提倡的“状态不可变”，

可以在面向对象中加入新的设计方式:

Class P { 状态a }

Class M {  }
Class N {  }

P的方法:

fun1{操作a b}

fun2{操作a b c}

fun3{通过M获得d}

fun4{通过N获得e f}

fun5{获得b}

fun6{获得c}

再一次简化“状态”，函数式的字面表示更趋向于“return”，而不是“=”赋值.

所以，对于不是特别重要的状态，对内存影响不重大的状态，

可以放入函数的return中.

而把特别重要的状态，经常变动并需要“缓存”“记忆”的状态保留.

再一次的减少维护状态的数量.

附注: 函数式另外的一种价值

Class P { fun1(m实例) {使用m的方法fun11；}  }

可以写为Class P { fun1(fun11) {使用fun11；}  }

这种方式对于“中介者”/控制器的动态能力，具有显著提升.