DRY原则--- Don‘t Repeat Yourself

DRY概述

降低可管理单元的复杂性的基本策略是将系统分成多个部分。

它通常以首字母缩写词DRY来指代

当您构建大型软件项目时，总体上通常会不知所措。人类不善于管理复杂性；他们擅长为特定范围的问题找到有创意的解决方案。降低可管理单元的复杂性的基本策略是将系统分成更方便的部分。首先，您可能需要将系统分为多个组件，其中每个组件代表自己的子系统，其中包含完成特定功能所需的一切。

例如，如果您要构建内容管理系统，则负责用户管理的部分将是组件。该组件可以分为其他子组件，例如角色管理，并且可以与其他组件（例如安全性组件）进行通信。

当您将系统划分为组件，再将组件划分为子组件时，您将到达一个将复杂性降低到单一职责的层次。这些职责可以在一个类中实现（假设我们正在构建一个面向对象的应用程序）。类
包含方法和属性。方法实现算法。算法以及算法的子部分（取决于我们想要获得的强迫性）
正在计算或包含构建业务逻辑的最小部分。

DRY原则指出，这些小知识在整个系统中可能只发生一次。

他们必须在其中具有单一表示。

每条知识都必须在系统中具有单一，明确，权威的表示形式。

如果要在CMS中实现数据库连接，则将有一个代码段，该代码段将初始化数据库驱动程序，传递凭据并将引用保存在变量中。代码段是知识的一部分，它与实现某些目标有关。引用连接的变量是该知识的表示，并且其他方可以使用。如果数据库凭据发生更改，我们将不得不更改代码段-而不是其表示形式。

在理想的应用程序中，每一个小的业务逻辑块都将其知识封装在一个表示形式中，即变量或类属性。
此变量本身封装在一个类中，该类可以描述为责任的表示形式。该类被封装在一个可以描述为功能性表示形式的组件中。

这可以继续进行，直到达到软件项目的最高级别为止，也就是一堆越来越复杂的表示形式。这种查看软件复杂性的方法称为模块化体系结构，而DRY是其中的重要组成部分。