设计原则主要从思想层面指导面向工具分析设计，设计模式则是针对某个场景下的某些问题的某个解决方案，是基于设计原则的详细实现。常见的六大面向工具设计原则单一职责原则 SRP（Single Responsibility Principle）一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。通俗地说，即一个类只卖力一项职责。

好比下单是一个职责，由专门的下单类卖力，付款是另一个职责，由专门的付款类卖力，而不是下单逻辑与付款逻辑混杂在同一个类中。解决的问题如果一个类卖力多个职责，当因为职责A的需求发生改变而需要修改代码的时候，有可能会导致原本运行正常的职责B功效发生故障。

实现方法职责单一看上去很是简朴，但也是因为太简朴，反而很难完全做到，难度在于如何区分职责，职责的粒度如何量化，这是个没有尺度化的工具。下单原本是一个职责，但下单方式会有许多种，差别的下单方式是否需要再细分？如果需要细分，那么下单类需要拆分成多个实现类，如果是在原有代码的基础上做拆分，就不仅需要修改下单类代码，还需要修改所有挪用方代码，十分消耗时间与精神。该如何遵守该设计原则，还得与实际情况联合。单一职责原则不仅适用的类，也可以小到适用于类中的一个方法，大到适用于一个微服务，一个系统，设计原则重要还是指导意义。

优点降低庞大度，职责单一，可以更好地明白业务，也可以更简朴地实现业务逻辑，与上下游的联系通过接口界说，开发人员只需要关注内部业务逻辑实现即可，在业务明白及实现上都可以越发准确。提高类的可读性，庞大度降低，可阅读性相应就会增强提高系统的可维护性，庞大度降低，可维护性相应增加降低变换可能引起的风险开放关闭原则 OCP（Open-Closed Principle）软件实体应当对扩展开放，对修改关闭开放关闭原则又称开闭原则，这是设计中很是焦点的一个原则。

解决的问题如果需求变化的时候，在不修改已有代码的情况下举行扩展。实现方法实现开闭原则的关键在于合理地抽象，分散出变化与稳定的部门，为变化的部门预留下可扩展的方式，好比钩子方法或者动态组合工具等。适度的抽象可以提高系统的灵活性，可是过分抽象会大大增加系统的庞大水平，在设计时需要制止陷入过分设计。

优点提高代码的可复用性提高系统的可维护性里氏替换原则 LSP（Liskov Substitution Principle）继续必须确保超类所拥有的性质在子类中仍然建立通俗地说，子类必须能够替换掉其父类，当一个类继续了另一个类，那么子类就应该拥有父类中可以继续的属性的操作，理论上来说，此时使用子类型去替代掉父类型，应该不会引起原来使用父类型的法式泛起错误。这是一个针对如何正确使用继续的设计原则。解决的问题父类新增了一个子类，可能导致原来使用父类的地方发生错误，原因是该子类重写了父类中的某些方法导致。

好比有一个电子表类，有一个方法为调整时间，原来运行正常，此时新增一个子类塑料表，虽然挂名电子表，但其实并不能对其调整时间，此时需要思量这个继续关系到底有没有问题。实现方法子类可以扩展父类的功效，但不能改变父类原有的功效，如果通过重写父类的方法来实现新的功效，会导致整个继续体系的可复用性变差，此时应该思量是否使用组合替代继续。优点从另外一个角度来说，里氏替换原则是实现开闭原则的重要方式之一。

开闭原则要求对扩展开放，扩展的一个实现手段就是继续，而里氏替换原则保证子类型能够正确替换父类型，只有正确替换，才气实现扩展，否则扩展了也会泛起错误。依赖倒置原则 DIP（Dependence Inversion Principle）高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象通俗地说，要依赖抽象，不要依赖详细实现解决的问题由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或抽象类，而细节则是指详细的实现类。使用接口或抽象类的目的是制定好规范和契约，而不去涉及任何详细的操作，把展现细节的任务交给它们的实现类去完成。

实现方法高层模块不应该依赖于底层模块，二者都应该依赖于抽象抽象不应该依赖于详细实现，详细实现应该依赖于抽象底层接口应该是由高层提出的，然后由底层实现的，也就是说底层的接口的所有权在高层模块，因此是一种所有权的倒置。优点降低类间的耦合性提高系统的稳定性淘汰并行开发引起的风险提高代码的可读性和可维护性接口隔离原则 ISP（Interface Segregation Principle）客户端不应该被迫依赖于它不使用的方法解决的问题这个原则用来处置惩罚那些比力 庞大 的接口，这种接口通常会有较多的操作声明，涉及到许多的职责。客户在使用这样的接口的时候，通常会有许多他不需要的方法，这些方法对于客户来讲，就是一种接口污染，相当于强迫用户在一大堆 垃圾方法 中寻找需要的方法。

实现方法只管将臃肿庞大的接口拆分成更小的和更详细的接口，让接口中只包罗客户感兴趣的方法优点接口隔离原则和单一职责原则都是为了提高类的内聚性，降低它们之间的耦合性，体现了封装的思想，但两者是差别的，差别在于：单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离单一职责原则主要是约束类，它针对的是法式中的实现和细节；接口隔离原则主要是约束接口，针对抽象和法式整体框架的构建最少知识原则 LKP（Least Knowledge Principle）只与你的直接朋侪攀谈，不跟“生疏人”说话如果两个类无须直接通信，那么就不应当发生直接的相互挪用，可以通过第三方转发该挪用。其目的是降低类之间的耦合度，提高模块的相对独立性。这个原则解决的问题最少知识原则又称迪米特规则，淘汰工具之间的交互，只跟自己的朋侪交互，降低类之间的耦合度，这样修改系统某一个部门的时候，就不会影响其它的部门，从而使得系统具胡更好的可维护性。

实现方法从依赖者的角度来说，只依赖应该依赖的工具。从被依赖者的角度说，只袒露应该袒露的方法。

优点降低类之间的耦合度，提高类的可复用率和系统的扩展性提高模块的相对独立性可是，如果过分使用迪米特原则，会使系统发生大量的中介类，导致系统的庞大度增加和模块之间的通信效率降低。其它原则面向接口编程优先使用组合，而非继续竣事语设计原则只是一个建议指导。

事实上，在实际开发中，很少做到完全遵守，还要综合思量业务功效、实现难度、系统性能、时间与空间等，所以总会在有意无意间违反部门设计原则。设计事情原来就是一个不停权衡的事情。

本文来源：ror体育-www.miouzhidai.com