设计模式原则

软件的可维护性

一个好的软件设计，必须能够允许新的设计要求以较为容易和平稳的方式加入到已有系统中

一个可维护性好的系统，应当允许维护工作能够以容易、准确、安全和经济的形式进行

导致软件可维护性较低的原因：

过于僵硬（缺乏可扩展性，新功能不容易加入系统）
过于脆弱（缺乏灵活性，修改某一模块会波及其他模块）
复用率低（开发其他系统又要重头开始开发各个功能模块，这往往是由于我们没有把一些通用的功能模块摘取出来加以封装导致的）

单一职责原则（SRP Single Responsibility Principle）

定义：即一个类或者模块只负责一项职责

或者可以定义为：就一个类或者模块而言，应该只有一个引起它变化的原因。

优点：

可以降低类的复杂度
提高类的可读性，提高系统的可维护性
变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响

里氏代换原则（LSP Liskov Substitution Principle）

定义：所有引用基类的地方必须能透明地使用其子类的对象。

通俗的讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能

里氏替换原则包含以下4层含义：

1. 子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。
2. 子类中可以增加自己特有的方法。
3. 当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

依赖倒置原则（DIP Dependence Inversion Principle）

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

总结：

低层模块尽量都要有抽象类或接口，或者两者都有。
变量的声明类型尽量是抽象类或接口。
使用继承时遵循里氏替换原则。
依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。

接口隔离原则（ISP Interface Segregation Principle）

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

通俗的来讲就是使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
总结：

接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不争的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。

迪米特法则又叫作最少知识原则（LKP Least Knowledge Principle）

定义：一个对象应该对其他对象保持最少的了解。

通俗的讲就是只与直接的朋友通信
总结：

由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系
类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象
朋友间也是有距离的，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。
是自己的就是自己的，如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中。

开闭原则 （OCP Open Closed Principle）

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
总结：

问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统

开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节
再回想一下前面说的5项原则，恰恰是告诉我们用抽象构建框架，用实现扩展细节的注意事项而已：单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。
最后说明一下如何去遵守这六个原则。对这六个原则的遵守并不是是和否的问题，而是多和少的问题，也就是说，我们一般不会说有没有遵守，而是说遵守程度的多少。任何事都是过犹不及，设计模式的六个设计原则也是一样，制定这六个原则的目的并不是要我们刻板的遵守他们，而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内，就算是良好的设计

对于软件来说，设计没有完美的，它总是一件需要取舍需要权衡的事，比如：时间换空间，空间换时间

聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。