DRY概述

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

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

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

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

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

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

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

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

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

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

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

DRY是一种将逻辑打包成表示形式的哲学

DRY 实现

有许多方法可以实现DRY 原则。亨特和托马斯建议（除其他外）代码生成器和数据转换。但是，从本质上讲，DRY是一种将逻辑打包为表示形式的哲学。

由于应用程序的每个部分都可以看作是表示形式，所以每个部分都暴露了底层逻辑的特定片段：用户管理暴露了CMS注册用户的访问权限，用户类代表单个用户并暴露了其属性（例如用户名） 。它通过数据库的表示检索属性。

DRY和模块化体系结构需要良好的计划。为了自下而上实现代表性的层次结构，请将您的应用程序划分为逻辑上分开的较小部分的层次结构，并让它们彼此通信。如果您必须管理较大的项目，请将它们组织成组件并在组件中使用DRY是个好主意。尝试应用以下规则：

• 对软件应用程序进行可视化层次结构，并映射到它的主要组件。复杂项目可能需要每个组件的专用映射。
• 如果您要达到连接职责的级别，则可能要切换到UML图（或类似图）。
• 在编写代码之前，请在软件项目中命名其层次结构。定义其代表的内容，并确保您知道其在周围组件中的作用。
• 定义表示形式应向其他方公开的内容（例如在数据库驱动程序中执行SQL的功能）以及应隐藏的内容（例如数据库凭据）。
  确保表示不依赖于另一个复杂度级别的表示（例如依赖于另一个组件中的类的组件）。

数据库驱动程序是一个简化的示例，因为在现实世界中涉及更多的层（例如特定的数据库抽象层），并且您可以做更多的事情来封装逻辑-特别是深入设计模式。但是，即使您刚开始编码，也要记住一件事：

当您发现自己编写的代码与之前编写的代码相似或相等时，请花点时间考虑一下自己在做什么，而不要重复自己。

在现实世界中，很难实现100％DRY的应用程序。然而，那些无法接受的应用（因此难以维护）是很常见的。因此，如果您要查看代码，则了解超过 50% 的软件项目失败并不奇怪。

许多人倾向于认为不良代码是由不良编码员产生的。以我的经验，这是一个很大的意外。不良代码通常是由不良客户经理和公司中流程管理的整体错误配置产生的。

错误的代码很少由错误的编码人员产生。

DRY原则是通过良好的规划来实现的。

例如，假设您被一家在代码质量和维护方面存在问题的公司聘为技术顾问。您查看源代码，会发现黑客 和代码重复-代码不是DRY。（原文： You review the source and you see hacks and code duplication - the code is not DRY.）这是代码质量差的征兆，这不是原因。如果您查看版本控制系统（又称代码的历史），您可能会发现在接近截止日期和里程碑的时间引入了一些hack。花时间检查所做的更改，您可能会遇到需求更改。

如上所述，通过良好的计划可以实现干度。在艰难的最后期限上进行强制更改正迫使开发人员实施肮脏的解决方案。一旦代码遭到破坏，DRY的原理很可能会在进一步更改时被完全牺牲。

IT行业最成功的公司之所以成立，是因为他们拥有非常熟练的技术知识甚至是自己的编码人员：Bill Gates，Mark Zuckerberg，Steve Wozniak，Steve Jobs，Larry Page，Sergey Brin和Larry Ellison know (or knew)需要付出什么努力才能实现某些目标。相反，许多公司倾向于将工程要求交到客户经理手中，并将概念要求交到业务顾问手中……从来没有实施过任何东西的人。

因此，许多技术概念只能在Powerpoint，Photoshop和27英寸宽屏显示器上使用。在或多或少的静态网站时代，这可能是一种成功的方法，但如今却不是-在多个设备上使用交互式应用程序。因为编码员是排在最后，所以他们必须对概念中的错误进行快速修复，如果这是由客户经理参与的，那么他们将无法忍受喜欢最后一刻的客户更改，计划被扔进垃圾桶，并实现了快速而又肮脏的操作，代码变得不DRY了。

这个例子有点极端（尽管如此，我已经目睹了这种情况），但它表明DRY是一个理论概念，受到现实世界中各方的挑战。如果您在一家强迫您以这种方式工作的公司中工作，则可能会建议对流程进行一些更改（例如在技术项目的早期引入技术专长）。

如果您有放手的方法，“YAGNI”（您“不需要） 原则将助您一臂之力。

原文：https://code.tutsplus.com/tutorials/3-key-software-principles-you-must-understand–net-25161

标签：DRY,Repeat,Don,更改,代码,应用程序,组件,数据库
来源： https://blog.csdn.net/ynchyong/article/details/112916682