销售准则、设计准则、缩写解释、反应、实践、单一任务准则、SRP，一个类或模块只负责完成一项任务(或功能) 粒度过细，会降低代码的内聚性，影响代码的可维护性。 先写一个粗粒度的类，满足业务需求，根据实际需要不断重构。 OCP的一个新功能应该是扩展现有的代码(添加新的模块、类、方法等)。)而不是修改现有代码(修改模块、类、方法等。) 支持这个标准的关键是保留扩展点，但是要小心过度设计。 只要变更没有破坏原代码和原单元测试的正常运行，我们就可以说是合格的代码变更。 Richter的criteria LSP子类对象可以替换程序中父类对象出现的任何地方，并保证原程序的逻辑行为不变，正确性不被破坏。 作为一个设计标准，它指导继承关系中的子类应该如何设计。 -根据协议进行设计。设计子类时，要遵循父类的行为约定，包括宣布和实现的功能，输入、输出和异常的约定，注释中的特殊说明。子类只能改变内部实现逻辑。 接口隔离标准不应强迫ISP接口的呼叫者或用户依赖它不需要的接口。 依赖反转准则DIP高层模块不应该依赖底层模块，但高层模块和底层模块应该通过通用性相互依赖。 其实在平时的业务代码开发中，高层模块对低层模块的依赖是毋庸置疑的。 该标准主要用于指导框架级别的设计。 接吻规则——尽量简单 不要使用同事可能不理解的技术来实现代码。 不要重复造轮子，要善于利用已有的工具类库。 不要过度优化。 不要过度使用几个奇怪的招数(比如用位运算代替算术运算，用复杂的条件语句代替if-else，使用几个太低级的函数等。)来优化代码，牺牲代码的可读性。 YAGNI标准-你不需要它。不要设计你目前不需要的功能；不要写目前不需要的代码。 核心思想是:不要过度设计。 比如暂时只用Redis存储配置信息，以后可能会用ZooKeeper。 那么我们在使用ZooKeeper之前就不需要提前写这部分代码了。 但是，这并不意味着我们不需要考虑代码扩展性。 我们仍然必须保留扩展点，然后在需要时实现ZooKeeper存储配置信息代码。 干准则——不重复自己。区分三种典型的重复情况:实现逻辑重复、功能语义重复、代码执行重复。 有时候，虽然代码的实现逻辑是一样的，但是语义不一样，那么就不违反DRY准则。 重复代码的问题可以通过将其归纳为更细粒度的函数来解决。 (isValidUserName()和isValidPassword()的例子)函数语义的重复通常违反了DRY准则。 (isValidIp()和checkIfIpValid()的例子)代码重复执行，这通常是违背DRY准则的，应该尽可能优化。 扩展:如何提高代码的复用性？减少代码耦合以满足单一职责准则，将模块化业务与非业务逻辑分离，通用代码下沉继承、多态性、通用性、应用模板封装等设计模式是辩证的:事实上，除非有非常明确的复用需求，否则为了满足暂时不用的复用需求而花费过多的时间和精力、投入过多的开发成本并不是一种推荐的做法。 这也违反了YAGNI准则。 LOD法则(迪米特里法则)——不应该有直接依赖的类之间不应该有依赖；在依赖类之间，尽量只依赖必要的接口。 凝聚力高:以班级为例。相似的函数应该放在同一个类中，不相似的函数不应该放在同一个类中。 松耦合:以类为例，类之间的依赖关系简单明了。 即使两个类有依赖关系，一个类的代码变化也不会或很少会导致依赖类的代码变化。 辩证:设计准则本身没有对错，只有对与不对。 不要为了应用设计标准而应用设计标准。当我们应用设计标准时，我们必须具体问题具体分析。 示例:序列化和反序列化可以分成两个接口吗？答案看情况。 如果序列化类只包含两个操作，就没有必要拆分，否则就违背了高内聚的思想。 但是如果序列化类增加了更多的函数，比如三个反序列化的函数，一旦任何一个反序列化的操作有代码变更，我们就需要检查测试所有依赖序列化的代码是否还能正常工作。 事实上，有些用户不需要了解反序列化的“知识”，他们只是使用序列化。 那么我们就应该根据迪米特里定律把反序列化和序列化的功能分开。