设计模式源码下载地址

1 单一功能原则

单一功能原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。所有它的（这个类的）服务都应该严密的和该功能平行（功能平行，意味着没有依赖）。

2 里氏替换原则

在面向对象的程序设计中，里氏替换原则（Liskov Substitution principle）是对子类型的特别定义。它由芭芭拉·利斯科夫（Barbara Liskov）在1987年在一次会议上名为“数据的抽象与层次”的演说中首先提出。

里氏替换原则的内容可以描述为： “派生类（子类）对象能够替换其基类（超类）对象被使用。” 以上内容并非利斯科夫的原文，而是译自罗伯特·马丁（Robert Martin）对原文的解读。其原文为：

Let q(x) be a property provable about objectsx of typeT. Thenq(y) should be true for objectsy of typeS whereS is a subtype ofT.

芭芭拉·利斯科夫与周以真（Jeannette Wing）在1994年发表论文并提出的以上的Liskov代换原则。----维基百科

里氏替换原则我个人的理解是：在继承关系中，父类的对象如果替换为子类的对象，他原来执行的行为依然保持不变，那么这样的程序才符合里氏替换原则，否则违背了里氏替换原则。

"围观"设计模式(2)--里氏替换原则(LSP,Liskov Substitution Principle)

3 依赖倒置原则

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

The principle inverts the way some people may think about object-oriented design, dictating that both high- and low-level objects must depend on the same abstraction.
----WIKIPEDIA
释义（读者可以试着自己翻译下，个人感觉第二句不好翻，不过蛮有意思的）：

在面向对象的程序设计中，依赖倒置原则是指解耦软件模块的特殊的形式。传统的依赖关系建立在高层次，而具体的策略设置应用在低层次上。使用依赖倒置原则，使得高层独立于底层的实现细节，依赖关系被倒置，使得低层次模块依赖于高层次模块的抽象。

原则规定：
A. 高层模块不应该依赖于低层模块，双方都要依赖于抽象类。
B. 抽象类不应该依赖于实现细节，实现细节应该依赖于抽象。
这项原则颠覆了一些人对面向对象程序设计的认识，比如：高层和低层都应该依赖于相同的抽象。
"围观"设计模式(3)--依赖倒置原则(DIP,Dependence Inversion Principle)

4 接口隔离原则

接口隔离原则（英语：interface-segregation principles，缩写：ISP）指明没有客户（client）应该被迫依赖于它不使用方法。接口隔离原则(ISP)拆分非常庞大臃肿的接口成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。这种缩小的接口也被称为角色接口（role interfaces）。接口隔离原则(ISP)的目的是系统解开耦合，从而容易重构，更改和重新部署。----WIKIPEDIA

个人对于接口隔离原则的理解是:
设计接口的时候，尽量保证实现接口的那些类尽可能一致的包含着接口中的方法，避免过多的设计了接口中的方法，导致其实现类中需要实现多个完全没有用处的方法（会造成代码的冗余和混乱）。
"围观"设计模式(4)--接口隔离原则(ISP,Interface Segregation Principle)

5 迪米特法则(最少知道准则)

得墨忒耳(迪米特)定律（Law of Demeter，缩写LoD）亦称为“最少知识原则（Principle of Least Knowledge）”，是一种软件开发的设计指导原则，特别是面向对象的程序设计。得墨忒耳(迪米特)定律是松耦合的一种具体案例。该原则是美国东北大学在1987年末在发明的，可以简单地以下面任一种方式总结:

    1. 每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；

    2. 每个单元只能和它的朋友交谈：不能和陌生单元交谈；

    3. 只和自己直接的朋友交谈。

这个原理的名称来源于希腊神话中的农业女神，孤独的得墨忒耳。

很多面向对象程序设计语言用"."表示对象的域的解析算符，因此得墨忒耳定律可以简单地陈述为“只使用一个.算符”。因此，a.b.Method()违反了此定律，而a.Method()不违反此定律。一个简单例子是，人可以命令一条狗行走（walk），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。----WIKIPIDIA

个人的理解：

面向对象的程序设计中，对象与对象之间尽量相互独立，具体对象的行为由具体的对象去完成，而不是由某个对象去指定另一个对象去实施行为而且是具体的行为。迪米特法则，核心的思想就是，要求我们在设计的时候，尽量避免类与类之间的耦合，弱化耦合关系可以提升复用率，但是这样的话，会产生中间的跳转类等，导致系统复杂。实际使用的过程中尽量在保证可读性与复杂性较低的情况下，按照迪米特法则去弱化类与类之间的耦合关系（高内聚、低耦合）。"围观"设计模式(5)--迪米特法则(Lod,Law of Demeter)或最少知道原则(Least Knowledge Principle)

6 开闭原则

在面向对象编程领域中，开闭原则规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的”，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变，因此无需上述的过程。

开闭原则的命名被应用在两种方式上。这两种方式都使用了继承来解决明显的困境，但是它们的目的，技术以及结果是不同的。----WIKIPEDIA

个人对于开闭原则的理解：

开闭原则相当于一个纲领性质的原则，提倡类等应该在设计完成后通过扩展的方式适应新的业务需求，而不是通过修改的方式去适应新的需求，这样的设计更加灵活、稳定。之前的五大原则是开闭原则思想的具体实现的情况。
"围观"设计模式(6)--开闭原则(Open/Closed Principle)

"围观"设计模式(28)--总结之设计模式六大准则