单一职责原则
类，方法引起它们改变的原因有且仅有一个。例如：工厂里的流水线，每个车间基本上只干一件事，所以车间组合起来就是一个生产流程。我们写程序的时候也可以这样，将一个类的功能细化一下争取做到一个类只做一件事。
下面是一个整条生成流程的例子
- 反例：
由此可见代码似乎并不是那么完美，显得臃肿，难以维护
- 正例：
此时有一个工厂，负责生产商品的整套流程，每个方法各司其职，负责自己车间该干的活。同时又提高了可读性和可维护性
（1）低耦合，高内聚
（2）类的复杂性降低，实现 什么功能都清晰明确定义
（3）可读性提高，可维护性提高
开闭原则
类应该对扩展开放，对修改关闭，一个类应该通过扩展来实现变化，而不能直接修改源代码。例如我们使用jdk的过程是符合开闭原则的，我们根本无法对jdk源码直接进行修改，我们只能通过jdk提供的已有的接口进行无限的扩展。
下面是我们的一个书店打折扣的活动
- 反例：
很显然这对我们后期的维护会造成巨大的损失
- 正例：
提供一个接口实现书本类重写价格的setter方法，并不影响我们原来的代码，而又扩展了新功能
（1）低耦合，高内聚
（2）降低系统耦合度，提高可复用性，提高可维护性
（3）“对扩展开放，对修改关闭”
（4）实现分离，不修改任何源代码
接口隔离原则
使用多个专一的接口比一个总接口要好，我们应该避免使用一个总的接口，而使用多个专一的接口。一个类对另一个类应该建立在最小的依赖上。接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个度只能根据经验和常识判断，没有一个固化或可测量的标准。
- 反例：
这样做不仅不美观，而且还会有多余的没用的代码，对于我们后期维护肯定是不友好的，多余的代码会让人费解。
- 正例：
每个都定义一个子接口，然后定义一个实现类，粒度最小化，一个类对另一个类应该建立在最小的依赖上。
（1）低耦合，高内聚
（2）提高系统的灵活性和可维护性
（3）接口粒度分离
里氏替换原则
任何可以使用基类的地方都应该可以透明的使用子类代替，并且不会影响程序正常运行，代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性，
- 反例：
会导致程序死循环
- 正例：
正方形不是长方形，不符合里氏替换原则，则只能抛弃继承
（1）低耦合，高内聚
（2）正方形不是长方形（非里斯替换原则，遵守原则则必须去掉继承）
（3）子类拥有父类的所有方法和属性，从而可以减少创建类的工作量。
（4）提高代码的复用性，提高了代码的扩展性，子类不但拥有了父类的所有功能，还可以添加自己的功能。
迪米特法则
又称“最少知道原则”，一个类对其他类知道的越少越好，就是说一个对象应当对其他的对象有尽可能少的了解，只和“朋友”通讯，不和陌生人说话。迪米特法则的意义在于降低系统之间的耦合度，由于每个对象尽量减少对其他对象的了解。
- 反例：
它们之间都在相互通讯，并不符合最少知道原则
- 正例：
通过朋友App2对陌生人Book2进行访问，对外界的联系降低至最小。
（1）低耦合，高内聚
（2）降低类与类之间的联系
依赖倒置原则
程序要依赖于抽象接口，不要依赖于具体的实现。高层模块不应该直接依赖于底层模块。简单的说就是面向接口编程，而不是面向现实编程。
- 反例：
饲养员直接依赖于动物，这样不仅工作量大，而且效率也会大打折扣。
- 正例：
提供一个动物抽象接口，让狗和猫实现这个动物的eat方法。饲养员只需要将饲料放到指定的位置，让动物自己去寻找食物即可。明显提高了工作效率，降低了工作量
（1）低耦合，高内聚
（2）减少模块对象直接的依赖
（3）降低耦合度，提高可复用性
总结
设计模式是需要时间来消化的，要在工作中不断的思考这种场合否适合使用设计模式，需要使用到那些设计模式将会写出更优越的代码，都是经验积累下来的，成为大神的途中是一种漫长且枯燥的过程。
23种设计模式中每一种都是为了解决特定场合的一套模式，在合适的时候使用更有利于我们的工作效率。不要一味的为了遵循设计原则，而放弃可能会有更高效率的设计方式。我们生活中往往也是这样，例如交通信号就是一种模式，如果不遵守后果将不堪设想。
96
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
