杂谈程序扩展性：

为什么经常说程序要有好的扩展性，扩展性到底指的啥？什么样的程序才叫有好的扩展性呢？为什么好的程序要有好的扩展性呢？没有不也能行吗？

随着查阅别人的解决方案的次数增多，就会经常性的发现“xxx有很好的扩展性”，“xxx代码保证了很好的扩展性”，“xxx程序实现了很好的扩展性”，等等等。有个东西天天搁耳边叨叨，即使不知道具体是什么意思，也会大概的在心里有个模糊的概念，比如它可以让插入功能变的更简单啊，比如写少量的代码就可以实现一个新的需求啊等等。

在我套用了一个mvc框架之后，我决定”实例化“一下那些经常看到，也可能经常用到，但会用不会说的那些个程序专业术语，比如“扩展性”。等我弄懂了这些个“名词”，下次给别人描述时就可以理所当然、理直气壮、财大气粗、花里胡哨的说：“我这个代码有非常好的扩展性！！！”，至于听的人明不明白，那就不能售后保证了，我只管在说的时候比听不懂的这个人有气势就行。

“扩展”的百度百科名词解释叫：指向外伸展；扩大范围或势力，那程序里不就是开发新的功能嘛！那么我稍稍想了一下，好的扩展性的重点应该不是“开发新功能”，而是开发新功能的“过程”，如果写的程序可以让开发新功能变得不复杂，或者很简单，那么这个程序就拥有了“好的扩展性”这么个光环。当然，能让开发新功能的过程变的简单化，这是实打实的好处，并不是虚的“花瓶”。

好的扩展性不仅代码结构清晰，降低开发者的工作量，稳定、使过程简单才是它的最终形态。

那什么样的代码才叫有好的扩展性呢？我开始的时候把它和多态搞混了，目前我认识的扩展性，它应该是对一个业务的流程归纳总结模块化。比如说电商业务，一般都会有浏览、下单、付款、配送等基础流程，如果把这些作为单独的模块并做好解耦，那下次需要在付款环节增加一种付款方式就不用每个模块都进行修改，只需修改付款流程即可，而如果对付款流程也做了足够的归纳抽象，抽象出了一个付款接口，新增加的付款方式只要实现了这个接口就可以无缝接入原来的付款流程，甚至如果还能进一步抽象出所有付款方式的通用属性，那一个抽象类就能进一步减少需要增加的代码，事实上提高扩展性的方法核心就是抽象出你的业务里不变的，恒定的东西，对于可变的，提前做好接口。比如mvc框架，它将数据，视图组件和控制逻辑进行了分离，新增的view和model不仅可以使用mvc框架提供的接口，而且它的新增并不会去改变其他的model和view。PMVC更是通过结合多个“设计模式”的应用，让耦合性变得更低。

仅仅就mvc框架来说，它已经提供了很好的一个可扩展性。就行游戏里的人物一样，对象式编程就像普攻，模块化增加了扩展性，就像学习了一个技能一样，扩展性的好差就像技能的威力一样，当你的代码有了很好的扩展性，是不是刷怪也变得简单了起来呢。而且这种技能市面上有很多优秀的，但是需要去学习，也可以自创。也可以。。。嗯，我的代码已经有了不差的扩展性。扩展性就是生产力啊。

当然扩展还分什么水平扩展、垂直扩展，这个就不说了，目前也没什么相应的实例可以说。

关于上面提到的解耦：耦合是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象，程序中其实就是对象之间的依赖性、关联性。对象之间的耦合越高，维护成本越高（改的东西多嘛），所以对象的设计应使其之间的耦合最小。完全没关系那也不可能，只是尽量彼此降低耦合，降低他们的关联性，原则就是A功能的代码不要写在B的功能代码中，想象一下，你如果只是想改个A的功能，却少不了要改B的代码，多麻烦，如果两者之间需要交互，可以通过接口，通过消息，甚至可以引入框架，但总之就是不要直接交叉写，这样改A的就改A好了，和B可以说没关系，精准定位，一击即中。例如观察者模式存在的意义就是「解耦」，它使观察者和被观察者的逻辑不再搅在一起，而是彼此独立、互不依赖。