软件架构设计模式大全 - vikipediaaaa

21-03-07 banq

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规则,每次提交时都应注意质量。不论大小,技术债务都会受到持续重构的抵制。
  • 每次提交时,请确保它不会降低代码库的质量。
  • 每当有人看到一些不尽如人意的代码时,他们都应该趁此机会在此位置进行修复。

 

命令查询分隔:

  • 命令查询分离原则指出,每种方法都应该是执行操作的命令,或者是将数据返回给调用方的查询,但不能两者都是。提出问题不应修改答案。
  • 有了这个原则,程序员可以更加自信地进行编码。由于查询方法不会改变状态,因此可以在任何地方以任何顺序使用。使用命令时,必须格外小心。
  • 通过将方法清楚地分为查询和命令,程序员可以放心地编写代码,而无需了解每种方法的实现细节。
  • 将每种方法实现为查询或命令
  • 将命名约定应用于方法名称,这暗示该方法是查询还是命令

1
猜你喜欢