1.KISS 原则

尽量保持简单

KISS 原则是保持代码可读和可维护的重要手段。KISS 原则中的“简单”并不是以代码行数来考量的。代码行数越少并不代表代码越简单，我们还要考虑逻辑复杂度、实现难度、代码的可读性等。而且，本身就复杂的问题，用复杂的方法解决，并不违背 KISS 原则。除此之外，同样的代码，在某个业务场景下满足 KISS 原则，换一个应用场景可能就不满足了。

2.YAGNI 原则

不要做过度设计

3. DRY 原则

俗称不要代码重复！
重复包括三种代码重复的情况：实现逻辑重复，功能语义重复，代码执行重复。
实现逻辑重复，但是功能语义不重复的代码，并不算违反DRY原则。实现逻辑不重复，但功能语义重复的代码，也算是违反DRY原则。除此之外，代码执行重复也算是违反DRY的原则

代码复用性

  • 减少代码耦合
  • 满足单一职责原则
  • 模块化
  • 业务与非业务逻辑分离
  • 通用代码下沉
  • 继承，多态，抽象，封装
  • 应用模板等设计模式

5.（LOD）迪米特法则

1. 如何理解“高内聚，低耦合”❓

高内聚低耦合是一个非常终重要的设计思想，能够有效提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。“高内聚”用来指导类本身的设计。“松耦合”用来指导类与类之间依赖关系的设计

所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一类中。相近的功能往往会被同时修改，当道同一个类中，修改就会比较集中，所谓松耦合是指 在代码中 类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的改动也不会或者很少导致依赖类的代码改动

2. 如何理解“迪米特法则”❓

不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。迪米特发展是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分，一旦发生变化，需要了解这一变化的类就会比较少