设计原则大全_设计方法里可以写设计原则吗-CSDN博客

本文链接：https://blog.csdn.net/Sun_ltyy/article/details/109392035

设计原则，是前人经验总结出来的，有效解决问题的指导思想和方法论。

在软件设计领域，前人总结出了很多设计上的原则，我们遵循这些原则可以非常容易的设计出，易维护、可扩展、灵活性的系统。

但是，这些设计原则是一种方法论、指导思想，我们不能教条，也需要根据实际需求懂得取舍。

一、SOLID原则

solid五个原则中，开闭原则和李氏替换原则是设计的目标，单一职责原则、接口隔离原则、依赖注入原则是设计的方法。

solid的五个原则，并不是相互独立的，违反其中一个原则，往往也会违反了其他原则

Single Responsibility Principle（SRP）：单一职责原则

此原则定义软件系统中的任何模块，应该只有一个单一的指责；衡量该指标的标准就是，是否只有一个被修改的原因；

模块的职责越单一，模块的内聚性越高，也容易被复用、容易被理解

Open CLose Principle（OCP）：开闭原则

软件开发完成后，一般都是都是需要功能扩展的，不存在开发完一次不需要迭代的情况。

既然要存在迭代，那我们如果是扩展新的功能，而对旧的代码很少改动，对修改关闭，那产生bug的问题就会很少，这就是我们所追求的。

在面向对象的变成过程中，我们通常使用多态和继承，封装不变的部分，把变化的部分开放出来。

很多的设计模式也都是以开闭原则为目标的。比如装饰者模式可以在不改变被装饰对象的情况下，通过wrap一个新类来扩展功能；策略模式通过制定一个策略接口，让不同的策略实现成为了可能；适配器模式在不改变原有类的基础上，让其适配新的功能；观察者模式，可以灵活的添加或删除观察者，扩展系统的功能.

Liskov Substitution Principle （LSP）：李氏替换原则

LSP认为，任何出现父类的地方，都可以正确的被子类型替换，并且程序能够正常工作，如果程序中出现了任何 instance of这种代码，很可能破坏了LSP原则，应该寻求解决

Interface Seperate Principle （ISP）：接口隔离原则

ISP接口隔离原则，我们不应该定一个大而全的接口，接口的定义也应该满足单一职责原则。比如在一个定义了四个方法的接口中，其实现类只需要用到其中一个方法，其它三个方法并不需要，需要额外的处理工作。

Dependency Inversion Principle （DIP）：依赖倒置原则

DIP依赖反转原则，模块之间的交互应该依赖抽象，而非具体的实现，虽然我们提倡多用组合，但是要加个限制条件，我们要依赖的是抽象，后续才能更好的扩展，能更大大提高系统的灵活性，因为我们只需要关系他们的特定契约，而非具体的实现。高层模块不应该依赖底层模块，两者都应该依赖抽象，高层依赖抽象，抽象不依赖细节，细节依赖抽象。

二、DRY 原则

Don't repeat yourSelf DRY,要求我们在代码编程中，不要出现多处重复的代码。众多重复的代码会降低代码的可读性、灵活性、可维护性。并且在需要修改时，需要修改多处，每一处还可能有不同的特殊逻辑点，造成代码的矛盾。遇到多处重复的代码，我们就要对此进行抽象出一个公共实现，或定义成接口。避免陷入散弹式编程的麻烦。

三、YAGNI

YAGNT you aint gonna not need it。这是极限编程提倡的原则，指导我们不要过度设计，该原则指出你以为的功能实际上是都用不到的。除了核心功能以外，其他的功能不要提前设计。极限编程提倡的尽可能快，尽可能简单的让软件运行起来。

四、Rule of Three原则

Rule of Three YAGNT原则和DRY原则其实是有冲突的，因为DRY要求我们高度抽象，要求找到通用的解决方法。YAGNT要求我们更快、更简单的解决问题。因此有了Rule of Three原则：当某一个功能第三次出现时，就要进行抽象化，这也是Martin fowler在《重构》一书中提到的思想。具体步骤是，当用到某个功能时写一遍代码，再用到时复制代码，第三次遇到时，就要开始着手于抽象出通用的解决方法了。该原则提醒我们既不要过度设计，也不能无设计。

五、KISS原则

KISS原则：keep it simple and stupid，保持代码的简单和愚蠢。这是在平衡计分卡理论中被提出来的，被运用到程序设计领域后，成了很多没有设计能力的程序员的挡箭牌。因此我们要打消这个误区，让简单变复杂简单，让复杂变简单复杂，我们一定要区分好简单和简陋，保持kiss，是需要大智慧的，并非毫无设计。