软件开发7大原则（这你不知道，Java白学了）

1.里氏替换原则-LSP: The Liskov substitution principle 

 子类必须能够替换基类(重要的） 

 子类不加额外约束 尽量继承抽象类接口（重要的)

a) LSP关注的是怎样良好的使用继承. 

b) 必须要清楚是使用一个Method还是要扩展它，但是绝对不是改变它。 

c) .LSP清晰的指出，OOD的IS-A关系是就行为方式而言，行为方式是可以进行合理假设的，是客户程序所依赖的。

d) LSP让我们得出一个重要的结论：一个模型如果孤立的看，并不具有真正意义的有效性。模型的有效性只能通过它的客户程序来表现。必须根 据设计的使用者做出的合理假设来审视它。而假设是难以预测的，直到设计臭味出现的时候才处理它们。 

e) 对于LSP的违反也潜在的违反了OCP 2.开放封闭原则-OCP（开闭原则，Open-Closed Principle） 对扩展开放，对更改封闭 使得应用程序具有更多的可维护性，可重用性以及可健壮性 想想:其实里氏替换原则也是开放封闭原则的一个基础 一个软件的实体应当对扩展开放，对修改关闭。我的理解是，对于一个已有的软件，如果需要扩展，应当在不需修改已有代码的基础上进行

3.单一职责原则-SRP(The single responsibility principle )

系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。SRP 让这个系统更容易管理维护，因为不是所有的问题都搅在一起。 如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化就可能削弱或者抑制这个类其它职责的能力。这种设计会导致脆弱的设计。当变化发生的时候，设计会遭到意想不到的破坏。 

4.接口隔离原则 

在设计时采用多个与特定客户类有关的接口比采用一个通用的接口要好不应该强迫客户程序依赖它们不需要的使用的方法。（客户端不应该依赖于自己不用的方法。）接口不是高内聚的，一个接口可以分成N组方法，那么这个接口就需要使用ISP处理一下。 接口的划分是由使用它的客户程序决定的，客户程序是分离的接口也应该是分离的。 一个接口中包含太多行为时候，导致它们的客户程序之间产生不正常的依赖关系，我们要做的就是分离接口，实现解耦。 应用了ISP之后，客户程序看到的是多个内聚的接口。 

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

依赖关系应该是尽量依赖接口（或抽象类），而不是依赖于具体类 高层不依赖低层，都依赖于抽象 针对接口编程，不要针对实现编程 我的理解是，对于不同层次的编程， 高层次暴露给低层次的应当只是接口，而不是它的具体类。 这里的倒置不仅仅是依赖关系的倒置也是接口所有权的倒置。应用了DIP我们会发现往往是客户拥有抽象的接口，而服务者从这些抽象接口派生。

6.组合(聚合)复用原则-DRY : Don't repeat yourself Principle

通过抽取公共部分放置在一个地方避免代码重复.尽量避免使用继承来复用代码多用组合，少用继承。

原因： 

 a、继承会使类无限膨大，可能会使类变得臃肿。 

 b、子类可能会继承父类中那些无用甚至有害的方法。

 c、组合比继承更灵活，可以实现在执行中动态改变对象的功能。

7.迪米特法则(Law of Demeter) 

对象间少通信,不要跟陌生人说话不会跟面向接口编程冲突众所周知类（或模块）之间的通信越少，耦合度就越低，从而更有利于我们对软件的宏观理。