Questions tagged «dry»

每当我编写单元测试时，我总是试图在每个测试中使用一个断言，以便在测试失败时简化调试。但是，当我遵循这个规则时，我感到我在每个测试中都在不断复制相同的代码，并且通过进行更多的测试，变得更难回头阅读和维护。 那么单断言测试是否违反DRY？ 而是否有一个很好的规律可循找到了很好的平衡，就像刚有每个方法一个测试？* *我意识到可能没有一种适合所有需求的解决方案，但是有没有建议的解决方法？

12 testing  unit-testing  dry 

为什么如此鼓励通过编写测试来重复自己？ 看起来测试基本上表达了与代码相同的内容，因此是代码的重复（从概念上讲，不是实现）。DRY的最终目标不包括消除所有测试代码吗？

11 testing  dry 

DRY原则（不要重复自己）指出：“每条知识都必须在系统中具有单一，明确，权威的表示形式。” 在大多数情况下，这是指代码，但它通常还扩展到文档。 据说每个软件系统都有一个体系结构，无论您是否选择它。换句话说，您构建的软件具有结构，而“已构建”结构就是软件的体系结构。 由于构建的软件系统具有体系结构，因此创建该系统的体系结构描述是否违反DRY原理？ 毕竟，如果您需要了解架构，那么您始终可以只看一下代码...

11 agile  documentation  architecture  dry 

我最近正在重构既是命令又是查询方法的方法。 将其分为一个命令方法和一个查询方法后，我发现代码中现在有多个地方可以调用命令，然后从查询中获取值，这似乎违反了DRY原理。 但是，如果我要将通用代码包装到一个方法中，则该方法既是命令又是查询。这可以接受吗？

10 language-agnostic  refactoring  dry  cqrs 

现在，我在编码中正在尝试DRY（不要重复自己）这个概念。我正在创建此函数，但我担心它变得太复杂了，但我尝试遵循DRY原理。 createTrajectoryFromPoint(A a,B b,C c,boolean doesSomething,boolean doesSomething2) 我说过的这个函数需要3个输入参数，然后在给定布尔组合doesSomething和的情况下，该函数会做一些稍有不同的事情doesSomething2。但是我遇到的问题是，随着每个新的布尔参数的添加，此函数的复杂性大大增加。 所以我的问题是，最好是让一堆不同的函数共享很多相同的逻辑（从而违反DRY原理），或者让一个函数在给定多个参数的情况下表现稍有不同，但使其复杂得多（但是保存DRY）？

10 java  design  dry 

使用OO语言（例如但不限于Java），如何根据重复发生的范围来修复重复的代码？我将从（例如）开始 在同一个类（范围）中执行提取方法重构（修复） 在相同层次结构的类（范围）中执行提取方法和上拉（修复） ...

10 object-oriented  dry 

我确信这个反模式在某处有个名字。但是，我对反模式文献还不了解。 请考虑以下情形： or0是类中的成员函数。不管好坏，它在很大程度上取决于类成员变量。程序员A随之出现，并且需要一些功能，例如or0而不是调用or0，程序员A复制并重命名整个类。我猜她不会打电话，or0因为正如我所说，它在很大程度上取决于成员变量的功能。或者，也许她是一个初级程序员，不知道如何从其他代码中调用它。因此，现在我们有了or0和c0（c为副本）。对于这种方法，我不能完全责怪程序员A －我们都在紧迫的期限内完成工作，并且我们乱砍代码以完成工作。 一些程序员or0对此进行了维护，使其成为当前版本orN。 c0现在是版本cN。不幸的是，维护类包含的大多数程序员or0似乎完全不知道-这c0是DRY原则的智慧中我能想到的最有力的论据之一。并且可能还已经独立维护了中的代码c。看来无论哪种方式，or0并c0维持相互独立的。而且，喜悦和幸福是错误的发生，cN而不会发生orN。 所以我有几个问题： 1.）此反模式有名称吗？我经常看到这种情况发生，我很难相信这不是一种命名的反模式。 2.）我可以看到一些替代方法： a。）修复orN一个参数，该参数指定了所需的所有成员变量的值。然后修改cN以调用orN所有传入的所需参数。 b。）尝试手动将修补程序从移植orN到cN。（请记住，我不想这样做，但这是现实的可能性。） c。）再一次复制orN到cN--yuck，但是出于完整性考虑，我列出了它。 d。）尝试找出cN损坏的地方，然后独立于对其进行维修orN。 从长远来看，替代a似乎是最好的解决方案，但我怀疑客户会允许我实施它。从来没有时间或金钱来解决问题，而是总是花费时间和金钱来解决同一问题40或50次，对吗？ 有人可以建议我可能没有考虑过的其他方法吗？

10 terminology  anti-patterns  dry 

我在代码库中感觉到太多抽象（或者至少是处理它）时遇到了问题。代码库中的大多数方法已被抽象为采用代码库中最高的父级A，但是此父级的子级B具有新属性，该属性会影响其中某些方法的逻辑。问题在于这些属性无法在那些方法中检查，因为输入被抽象为A，而A当然没有此属性。如果我尝试创建一个新的方法来不同地处理B，则会被调用以进行代码复制。我的技术负责人的建议是创建一个使用布尔参数的共享方法，但是这样做的问题是，有些人将其视为“隐藏的控制流”，其中共享方法具有的逻辑对于将来的开发人员可能并不明显。 ，并且即使需要添加将来的属性，即使将其分解为较小的共享方法，该共享方法也会变得过于复杂/复杂。这也增加了耦合，降低了凝聚力，并且违反了我团队中有人指出的单一责任原则。 本质上，此代码库中的许多抽象有助于减少代码重复，但是当使它们采用最高抽象时，这会使扩展/更改方法变得更加困难。在这种情况下我该怎么办？尽管其他人不能就他们认为的好事达成共识，但我还是要怪罪于我，这最终伤害了我。

9 object-oriented-design  class-design  abstraction  code-reuse  dry 

我想以DRY方式编写Javadoc。但是关于Javadoc的Oracle文档说在重载方法注释中再次写同样的东西。我不能避免重复吗？

9 documentation  comments  dry  javadocs