软件腐化的原因:--可维护性才是王道
软件腐化的原因:--可维护性才是王道
1过于僵硬 相反:要使软件具有 可扩展性（新性能可以很容易加入系统）
2过于脆弱 灵活性（修改不会波及其它）
3复用率低
4粘度过高 可插入性（新功能容易加入系统（气囊加入方向盘））
解释:
过于僵硬、过于脆弱、复用率低、粘度过高的系统都必然导致可维护性的减弱。反过来，可扩展、可插入、灵活的设计是提高可维护性的基础，但不一定能够保证可维护性。
有些人开发的系统高度灵活，所有数据库字段都可以动态添加、删除，表也可以动态构建。可以说灵活性高、可插入、可扩展性也很强。但导致代码超级复杂，读起来根本就找不到北，更不用说修改了。这时候，可维护性就显得很低。甚至在维护代码时，不小心触动一些关键部件造成系统出现问题。
有时候我提倡为开发人员写代码（注意：不是注释）。有些代码不是给客户用的，而是给开发人员用的。包括必要的错误定位工具，内部调试断点，性能计数器等等。这些代码可以帮助提高系统的可维护性。
总之，可维护性是一个综合的概念，任何人都无法预料客户需求会发生什么样的变化，“未雨绸缪”和“亡羊补牢”都是提高可维护性的一个很好切入点。测试驱动开发以及契约式开发对提高可维护性也有不少帮助。
提高系统可复用性的几点原则：
传统复用：
1. 代码的粘帖复用
2. 算法的复用
3. 数据结构的复用
* 可维护性与可复用性并不完全一致
应用下面原则可以调高程序的可维护性:
一、 "开放－封闭"原则(OCP)
Open-Closed Principle原则讲的是：一个软件实体应当对扩展开放，对修改关闭。
二、 里氏代换原则（LSP）
Liskov Substitution Principle（里氏代换原则）：子类型(subtype)必须能够替换它们的基类型。
三、 依赖倒置原则(DIP)
四、 接口隔离原则（ISP）
五、 合成/聚合复用原则（CARP）
六、 迪米特法则（LoD）
一、 "开放－封闭"原则(OCP)
要求我们在设计软件的时候,应尽可能使软件有扩展性,封闭性
Open-Closed Principle原则讲的是：一个软件实体应当对扩展开放，对修改关闭。
优点：
通过扩展已有软件系统，可以提供新的行为，以满足对软件的新的需求，使变化中的软件有一定的适应性和灵活性。
已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。
生动的例子:
例子：玉帝招安美猴王
当年大闹天宫便是美猴王对玉帝的新挑战。美猴王说："'皇帝轮流做，明年到我家。'只教他搬出去，将天宫让于我！"对于这项挑战，太白金星给玉皇大帝提出的建议是："降一道招安圣旨，宣上界来…，一则不劳师动众，二则收仙有道也。"
换而言之，不劳师动众、不破坏天规便是"闭"，收仙有道便是"开"。招安之道便是玉帝天庭的"开放－封闭"原则。
招招安之法的关键便是不允许更改现有的天庭秩序，但允许将妖猴纳入现有秩序中，从而扩展了这一秩序。用面向对象的语言来讲，不允许更改的是系统的抽象层，而允许更改的是系统的实现层。
二、 里氏代换原则（LSP）
Liskov Substitution Principle（里氏代换原则）：子类型(subtype)必须能够替换它们的基类型。
反过来的代换不成立
《墨子·小取》说："娣，美人也，爱娣，非爱美人也……"娣便是妹妹，哥哥喜爱妹妹，是因为两人是兄妹关系，而不是因为妹妹是个美人。因此，喜爱妹妹不等同于喜爱美人。用面向对象语言描述，美人是基类，妹妹是美人的子类。哥哥作为一个有"喜爱()"方法，接受妹妹作为参数。那么，这个"喜爱()"方法一般不能接受美人的实例。
三、?依赖倒置原则(DIP)
依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。
简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：
抽象不应当依赖于细节；细节应当依赖于抽象；
要针对接口编程，不针对实现编程。
反面例子：
缺点：耦合太紧密，Light发生变化将影响ToggleSwitch。
解决办法一：
将Light作成Abstract，然后具体类继承自Light。
优点：ToggleSwitch依赖于抽象类Light，具有更高的稳定性，而BulbLight与TubeLight继承自Light，可以根据"开放－封闭"原则进行扩展。只要Light不发生变化，BulbLight与TubeLight的变化就不会波及ToggleSwitch。缺点：如果用ToggleSwitch控制一台电视就很困难了。总不能让TV继承自Light吧。
解决方法二：
?
优点：更为通用、更为稳定。
结论：
使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。
四、?接口隔离原则（ISP）
接口隔离原则（Interface Segregation Principle）讲的是：使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。
过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
五、?合成/聚合复用原则（CARP）
合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）经常又叫做合成复用原则（Composite Reuse Principle或CRP），就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。
简而言之，要尽量使用合成/聚合，尽量不要使用继承。
六、?迪米特法则（LoD）
迪米特法则（Law of Demeter或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP），也就是说，一个对象应当对其它对象有尽可能少的了解。
其它表述：
??只与你直接的朋友们通信
??不要跟"陌生人"说话
??每一个软件单位对其它的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
迪米特法则与设计模式
Facade模式、Mediator模式
使民无知
《老子》第三章曰："是以圣人之治，虚其心，实其腹，弱其志，常使民无知无欲。"使被"统治"的对象"愚昧"化，处于"无知"的状态，可以使"统治"的成本降低。
所谓"最少知识"原则，实际上便是老子的"使民无知"的统治之术。
不相往来
《老子》云："小国寡民……邻国相望，鸡犬之声相闻，民至老死，不相往来。"将被统治的对象隔离开来，使它们没有直接的通信，可以达到分化瓦解，继而分而治之的效果。迪米特法则与老子的"小国寡民"的统治之术不谋而合。
