所谓的原则：编码设计时所依据的法则或标准
一.单一责任原则（Single Responsibility Principle 简称SRP）
定义: 一个类应该有且仅有一个原因引起类的变更
解析：现在又很多小型公司每个人都是身兼多职，比如人A原本是行政但他又做着人事的工作，那A的职责就是 “人事P1”和“行政P2”两个职责。当人事的工作内容变化时（工作量增大）那有可能就忙不过来从而导致行政的工作会受到影响。按照单一原则为了不影响行政的工作只能再招一个人事，人A就只负责行政。
A（类）有两个职责 一个P1 P2。P1，P2的改变都导致A（类的改变）。类和方法都只负责一项职责
优点：
1.类的复杂性降低
2.可读性提高
3.可维护性提高
4.维护成本降低
二.里氏替换原则（Liskov Substitution Principle 简称LSP）
定义: 所有引用基类的地方必须能够透明地使用其之子类对象
解析：父类使用的地方都能用之类替换，子类可以扩展（增加）功能，但不能改变原有父类的功能,比如一个人因为公司需要顶替了财务，那你不能改变财务原先的工作内容。
优点：更够提高程序的稳定性和可移植性
三.依赖倒置原则（dependence inversion principle 简称DIP）
定义：
1.上层模块不应该依赖下层模块，两者应依赖其抽象；
2.抽象不应该依赖细节，细节应该依赖抽象；
解析:从编码角度来说，其实就是不能依赖具体的实现类。依赖关系传递有三种：构造方法注入，set方法注入，接口声明。假如现在有个A类构造方法里需要一个入参B类（具体的实现类）对象。而B类继承或实现了 C(接口或者是抽象类)。
此时不使用原则构造方法写法： A（B b）{}
而使用原则的写法: A(C b){}
也可以理解为 面对接口编程
优点:
1.减少类之间的耦合（解耦）
2.提高系统稳定性
3.提高可读性和可维护性
四.接口隔离原则（interface segregation principle 简称ISP）
定义:
1.客户端不应该依赖它不需要的接口；
2.类之间依赖关系应该建立在最小的接口上；
解析:如果一个类实现了一个接口，但接口中的部分方法没有具体实现功能。那接口就应该拆分成2个甚至多个接口。接口中仅包含为某一类定制的方法，而不应该强迫类去依赖于那些它们不用的方法。但如果严格按照接口隔离来编码系统里肯定会存在大量的接口，会导致系统很难维护。所有这个拆分（隔离）接口的力度一定要适当。
优点：
1.拆分庞大的接口，可以提高系统灵活性和可维护性
2.减少代码冗余
五.迪米特法则（Law Of Demeter 简称LoD）
定义:一个软件实体应当尽可能少地与其他实体发生作用
解析:要做到尽可以减少其它实体发生作用，一般有两点：
1.只暴露该暴露的方法或属性，其实就是尽可能的把方法或属性设置为私有。
2.只依赖应该依赖的对象
实体与实体之间的关系一般分为：依赖，关联，组合，聚合（继承 和实现）。如果不存在这样的关系就不能发生作用（互相调用 new对象之类的操作），但可以通过有关系的实体间接的调用操作
优点: 1.能够减少类之间的耦合
六.开闭原则（open closed principle 简称OCP）
定义：一个软件实体应当对扩展开放，对修改关闭
解析:当需求变化导致系统需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。其实我们在日常维护中经常做这样的事情，比如说现在要给A调整一个功能，我们可能会新建一个类B 然后在B里增加一个方法（功能）。而不是之间在A类里修改
优点:
1.提高代码复用性
2.提高维护性
不管有没有学过或者了解过设计原则或者设计模式，其实在长时间的编码养成的习惯中自然而然的知道这样写或者那样写好一些，这就是经验的积累。而设计模式和设计原则就是前辈们多年经验的总结。
代码设计都是为了解耦，灵活。在开发中其实很少能够严格遵守原则，比如说单一责任原则，如果严格按照编写会产生大量的类和接口，这不管是开发上还是后期维护上都是很麻烦的。说得实在一点甚至会影响开发进度。所以应该根据项目情况来找到一个平衡点。不管怎么样实现了功能才是第一要素。
网友评论