KISS(保持简单愚蠢):
- 即使解决方案看起来很愚蠢,简单的解决方案也比复杂的解决方案好。
- 当解决方案使用较少的继承,较少的多态性,较少的类等时,解决方案会更好。
- 更简单的解决方案更易于维护,即检测和纠正缺陷更加有效。
YAGNI(您将不需要它):
- 除非有必要,否则不要实施某些东西。
- 快速实现代码的最佳方法是少执行代码。减少错误的最好方法是减少代码。
做可能可行的最简单的事情:
- 首先,以您认为“可能可行”的最简单方式实现一项新功能。不要建立很多惊人的上层j架构,不要做任何花哨的事情,只需将其放入即可。甚至使用if语句。使代码通过新功能(以及所有功能,一如既往)的UnitTests。
- 其次,这对于规则至关重要,因此将系统重构为尽可能简单的代码,包括其现在具有的所有功能。遵循OnceAndOnlyOnce规则和其他代码质量规则,以使系统尽可能干净。
- 对于IterativeDevelopment的每次增量,都应该做可能会起作用的最简单的事情。为此,您必须至少知道两种执行此操作的方法。这样,您至少可以选择较简单的(如果不是最简单的话)。
关注点分离 :
- 将计算机程序分成不同的部分,以便每个部分都解决一个单独的问题。
- 例如,应用程序的业务逻辑是一个问题,而用户界面是另一个问题。更改用户界面不应要求更改业务逻辑,反之亦然。
- 当关注点分开时,各个部分可以重复使用,也可以独立开发和更新。
- 将程序功能分成尽可能少的重叠的单独模块。
保持干DRY:
- 程序中的每个重要功能都应该在源代码中的一个位置实现。在类似的功能由不同的代码段执行的情况下,通常可以通过抽象出不同的部分将它们组合为一个代码,这通常是有利的。
- 复制(无意或有目的的复制)可能导致维护方面的噩梦,分解不佳以及逻辑上的矛盾。
- 修改系统的任何单个元素都不需要更改其他逻辑上不相关的元素。
- 另外,逻辑上相关的元素都可预测且一致地更改,因此保持同步。
- 仅将业务规则,长表达式,if语句,数学公式,元数据等放在一个位置。
- 确定系统中使用的每条知识的唯一且确定的来源,然后使用该来源生成该知识的适用实例(代码,文档,测试等)。
为维护编码:
- 迄今为止,维护是所有项目中最昂贵的阶段。
- 始终进行这样的编码:就像最终维护您的代码的人是知道您的住所的暴力心理变态者一样。
- 始终以这样的方式进行编码和注释:如果初级的一些人发现了一些密码,他们会很乐于阅读和学习。
避免过早优化:
- 在您需要进行优化之前,不要进行优化,只有在进行性能分析之后,您才发现优化瓶颈。
- 经过优化后,可能难以阅读并难以维护。
最小化耦合:
- 模块/组件之间的耦合是它们相互依赖的程度;耦合度越低越好。换句话说,耦合是在对代码单元“ A”进行未知更改后,代码单元“ B”将“中断”的概率。
- 消除,最小化和减少必要关系的复杂性。
- 通过隐藏实现细节,减少了耦合。
得墨meter耳定律:
- 不要跟陌生人说话。
- 通常会紧耦合
- 它可能会透露太多实施细节
- 对象的方法只能调用以下方法:
- 对象本身。
- 方法的参数。
- 在方法内创建的任何对象。
- 对象的任何直接属性/字段。
组合而不是继承
- 类之间的耦合较少。
- 使用继承,子类可以轻松地进行假设并打破LSP。
- 测试LSP(可替代性)以决定何时继承。
- 在存在“具有”(或“使用a”)关系时进行撰写,在“是a”的情况下进行继承。
正交性
- 正交性的基本思想是,在概念上不相关的事物不应在系统中相关。
- 它与简单性相关。设计越正交,例外就越少。
- 这样可以更轻松地学习,阅读和编写使用编程语言编写的程序。
- 正交特征的含义与上下文无关;关键参数是对称性和一致性。
稳健性原则
- 对自己的工作要保守一些,对别人所接受的事情要开放一些
- 为了能够发展服务,您需要确保提供商可以进行更改以支持新需求,同时最大程度地减少对现有客户的破坏。
- 向其他计算机(或同一计算机上的其他程序)发送命令或数据的代码应完全符合规范,但是,只要含义清楚,接收输入的代码应接受不合格的输入。
控制反转:
- 控制反转也被称为好莱坞原则,“不要打电话给我们,我们会打电话给您”。
- 它是一种设计原理,其中计算机程序的自定义编写部分从通用框架接收控制流。
- 控制反转具有很强的内涵,即可重用代码和特定于问题的代码是独立开发的,即使它们在应用程序中一起运行也是如此。
- 控制反转用于增加程序的模块化并使其可扩展。
- 可以使用Factory模式,Service Locator模式,依赖注入,上下文相关的查找,Template Method模式,Strategy模式来实现控制反转
最大化内聚性:
- 单个模块/组件的凝聚力是其职责形成有意义的单元的程度;凝聚力越高越好。
里斯科夫换人原则:
- LSP是关于对象的预期行为的。
- 程序中的对象应该可以用其子类型的实例替换,而不会改变该程序的正确性。
开/关原则:
- 软件实体(例如类)应为扩展而开放,但为修改而封闭。即,这样的实体可以允许在不更改其源代码的情况下修改其行为。
- 通过最小化对现有代码的更改来提高可维护性和稳定性。
- 编写可以扩展的类(与可以修改的类相反)。
- 仅暴露需要改变的运动部件,隐藏其他所有部件。
单一责任原则:
- 每个班级应负一个单一的责任,而该责任应由班级完全封装。责任可以定义为变更的原因,因此,一个类或模块应该只有一个变更原因。
- 可维护性:仅应在一个模块或一个类中进行更改。
隐藏实施细节:
- 软件模块通过提供接口来隐藏信息(即实现细节),并且不会泄漏任何不必要的信息。
- 当实现更改时,客户端使用的接口不必更改。
- 最小化类和成员的可访问性。
- 不要公开公开会员数据。
- 避免将私有实现细节放入类的接口中。
- 减少耦合以隐藏更多实现细节。
卷曲定律:
- 卷曲定律是关于为任何特定代码段选择一个明确定义的目标:做一件事情。
封装变化了什么:
- 好的设计可以识别最有可能发生变化的热点,并将其封装在API之后。然后,当发生预期的更改时,修改将保留在本地。
- 最小化发生变更时所需的修改
- 封装了API背后的概念
- 可能将变化的概念分成自己的模块
接口隔离原理:
- 将胖接口减少为多个更小,更具体的客户端特定接口。接口应该比实现它的代码更依赖于调用它的代码。
- 如果一个类实现了不需要的方法,则调用者需要了解该类的方法实现。例如,如果一个类实现一个方法而仅仅抛出一个方法,则调用者将需要知道实际上不应该调用此方法。
- 避免胖接口。类永远不必实现违反单一职责原则的方法。
童子军规则:
- 美国的童子军有一个简单的规则可以应用到我们的职业中:“让营地比您发现的要干净”。童子军规则指出,我们应始终将代码保留得比发现的干净。
- 在更改现有代码库时,代码质量趋于下降,从而增加了技术负担。遵循boyscout规则,每次提交时都应注意质量。不论大小,技术债务都会受到持续重构的抵制。
- 每次提交时,请确保它不会降低代码库的质量。
- 每当有人看到一些不尽如人意的代码时,他们都应该趁此机会在此位置进行修复。
命令查询分隔:
- 命令查询分离原则指出,每种方法都应该是执行操作的命令,或者是将数据返回给调用方的查询,但不能两者都是。提出问题不应修改答案。
- 有了这个原则,程序员可以更加自信地进行编码。由于查询方法不会改变状态,因此可以在任何地方以任何顺序使用。使用命令时,必须格外小心。
- 通过将方法清楚地分为查询和命令,程序员可以放心地编写代码,而无需了解每种方法的实现细节。
- 将每种方法实现为查询或命令
- 将命名约定应用于方法名称,这暗示该方法是查询还是命令