设计原则

单一职责原则（SRP）
描述：就一个类而言，应该仅有一个引起它变化的原因。
应用：在构造对象时，将对象的不同职责分离至两个或多个类中，确保引起该类变化的原因只有一个。
带来的好处：提高内聚、降低耦合。
用通俗的话说:就是一个类只能做一件事.
在设计模式中用到的主要是:策略模式,状态模式，观察者模式.

开放-封闭原则（OCP）

描述："对于扩展是开放的"（Open for extension）。这意味着模块的行为是可以扩展的。

当应用的需求改变时，可以对模块进行扩展，使其具有满足改变的新行为。也就是说，我们可以改变模块的功能。

"对于更改是封闭的"（Close for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。
应用：高级语言中的接口与虚拟类。
带来的好处：提高灵活性、可重用性、可维护性。
个人观点：OCP的关键是抽象，抽象的目的是创建一个固定却能够描述一组任意个可能行为的基类。而这一组可能的行为则表现为派生类。对于基类的更改是封闭的，所以它里边的方法一旦确定就不能更改（对接口里的方法进行更改将带来灾难性的后果）。
模块通过抽象基类进行引用，对派生类的扩展并不影响整个模块，所以它是开放的。遵循OCP的代价也是昂贵的，创建正确的抽象是要花费开发时间和精力的，同时抽象也增加了软件设计的复杂性。因此有效的预知变化是OCP设计的要点，这需要我们进行适当的调查，提出正确的问题，并利用我们的经验和一般常识来做出判断。正确的做法是，只对程序中频繁变化的部分做出抽象，拒绝不成熟的抽象和抽象本身一样重要。
在设计模式中用到的主要是:策略模式,观察者模式.

Liskov替换原则（LSP）
描述： 父类的方法都要在子类里实现或者重写,不允许子类出现父类所没有定义的方法.
在设计模式中用到的主要是:组合模式.

依赖倒置原则（DIP）
描述：
A .高层模块不应该依赖于低层模块。二者都应该依赖于抽象。
B .抽象不应该依赖于细节。细节应该依赖于抽象。
应用：要依赖抽象，不要依赖于具体。即针对接口编程，不要针对实现编程。
针对接口编程的意思是，应当使用接口和抽象类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。不要针对实现编程的意思就是说，不应当使用具体类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。
在设计模式中用到的主要是:模板模式,观察者模式.
通俗的话说:只能子类调用父,不能父类调用子类.

接口隔离原则（ISP）
描述：不要强迫客户依赖于它们不用的方法。
应用：如果客户端只需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法。
结论：使用多个专门的接口比使用单一的接口要好。
最经典的实例:适配器中的对象适配器。

迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解, 不和陌生人说话。英文简写为: LoD.
门面模式就是迪米特法则的应用。
通俗的说:将用户不用的方法私有化,将不变的字段用final来修饰.

抽象类和接口的区别：
抽象类是一个类.
接口是一种行为,接口是类的一部分.
接口比抽象类的扩展性更好。

Liskov替换原则（LSP）
描述： 父类的方法都要在子类里实现或者重写,不允许子类出现父类所没有定义的方法.
在设计模式中用到的主要是:组合模式.


"不允许子类出现父类所没有定义的方法."-------这一行怎么理解？

楼主关于LSP的解释是错误的。LSP的精髓是，使用父类的代码可以完全无障碍地使用子类，也即任何使用父类实例的地方，可以被替换为子类的实力，而不会引起行为的差别。

子类不能定义自己的方法的限制更是完全错误的。子类可以扩展公共接口，但是父类的使用者不知道这些接口，也就无法使用他们了。因此这些扩展只对于子类及其子类的使用者有用。

这种UI框架的设计中非常常见。

如果想用父类没有的方法.
需要强制向下转型.....
当然如果一开始你就不使用父类或接口就会有这样问题了....