Questions tagged «dry»

我一直在工作中严格遵循DRY原则；每次我由于懒惰而重复编写代码时，都会在以后需要在两个地方维护该代码时再次出现。 但是我经常写一些小的方法（可能是10到15行代码），这些方法需要在两个不能互相引用的项目中重用。该方法可能与网络/字符串/ MVVM等有关，并且是一种通用的有用方法，并不特定于它最初所在的项目。 重用此代码的标准方法是为可重用代码创建一个独立的项目，并在需要时引用该项目。问题在于，我们最终遇到了两种不理想的情况之一： 我们最终得到了数以百计的小项目-每个小项目都包含我们需要重用的小类/方法。.DLL仅需少量代码就可以创建一个全新的应用程序吗？ 我们最终完成了一个项目，其中包含越来越多的不相关方法和类。这种方法是我曾经工作过的公司所做的。他们有一个名为的项目base.common，其中包含用于我上面提到的事情的文件夹：联网，字符串处理，MVVM等。它非常方便，但是不必要地将其与所有不需要的无关代码一起拖到它。 所以我的问题是： 软件团队如何最好地在项目之间重用少量代码？ 我特别感兴趣的是，如果有人在一家在这方面有政策的公司工作，或者像我本人那样亲自遇到了这个难题。 注意：我对“项目”，“解决方案”和“参考”一词的使用来自Visual Studio .NET开发的背景。但是我敢肯定，这个问题与语言和平台无关。

102 project-management  code-reuse  projects-and-solutions  dry 

非常简单，当我需要做的就是重复几次相同的过程并做一些细微调整后，为什么还要编写适用于所有情况和可伸缩数据的代码？ 我不太可能需要在不久的将来再次进行编辑。 看起来要减少很多工作... function doStuff1(){/*.a.*/} function doStuff2(){/*.b.*/} function doStuff3(){/*.c.*/} 如果我需要添加一些内容... function doStuff4(){/*.d.*/} 如果我需要将其删除，则可以将其删除。 很难弄清楚如何将所有这些都变成一个简单的模式，以便我可以将数据输入并处理所有情况，并进行很多我不希望拥有的更改去做。 当看起来像快速剪切+粘贴会减少工作量时，为什么要干呢？

81 code-quality  dry 

例如，考虑我有一个可供其他类扩展的类： public class LoginPage { public String userId; public String session; public boolean checkSessionValid() { } } 和一些子类： public class HomePage extends LoginPage { } public class EditInfoPage extends LoginPage { } 实际上，子类没有任何方法可以覆盖，也不会以通用方式访问HomePage，即：我不会做类似的事情： for (int i = 0; i < loginPages.length; i++) { loginPages[i].doSomething(); } 我只想重用登录页面。但是根据https://stackoverflow.com/a/53354，我在这里更喜欢合成，因为我不需要LoginLog接口，所以在这里我不使用继承： public class HomePage { …

36 inheritance  composition  dry 

我有一些几乎相同的代码，但是在主变量上使用绝对不同的类型，它们之间没有继承。具体来说，我正在用Roslyn针对C＃和VB.NET编写具有以下类型的分析器： Microsoft.CodeAnalysis.CSharp.Syntax.AttributeSyntax Microsoft.CodeAnalysis.VisualBasic.Syntax.AttributeSyntax 我想知道是否因为代码在做相同的事情，我应该将其保持为DRY，将其尽可能少地拆分为单独的（但类型除外），还是将它们完全分开，因为这两种方法是不相关，将来的更改可能会迫使一个版本更改，而另一个版本则不能更改（尽管这不太可能）？ 编辑：大约一年后，我遇到了同样的问题，罗斯林（Roslyn）团队帮助我解决了这个问题：编写一个采用泛型并具有TAttributeSyntax完成大部分工作的参数的基类。然后，使用最少的需要特定类型的数据编写派生类。

34 c#  design  dry 

我想知道在良好的OOP设计，干净的代码，灵活性以及将来避免代码异味方面有什么更好的选择。图像情况，您需要将很多非常相似的对象表示为类。这些类没有任何特定的功能，只是数据类，而只是名称（和上下文）不同而已。示例： Class A { String name; string description; } Class B { String name; String count; String description; } Class C { String name; String count; String description; String imageUrl; } Class D { String name; String count; } Class E { String name; String count; String imageUrl; String age; …

24 object-oriented  inheritance  dry 

我有几个类都从通用基类继承。基类包含一些类型为的对象的集合T。 每个子类都需要能够从对象集合中计算插值，但是由于子类使用不同的类型，因此每个类之间的计算差异很小。 到目前为止，我已经在每个类之间复制/粘贴了我的代码，并对每个代码进行了较小的修改。但是现在我试图删除重复的代码，并在我的基类中将其替换为一种通用插值方法。但是，事实证明这非常困难，而且我所想到的所有解决方案似乎都太复杂了。 我开始认为DRY原则在这种情况下不太适用，但这听起来像是亵渎神灵。尝试删除代码重复时有多少复杂性？ 编辑： 我能想到的最好的解决方案是这样的： 基类： protected T GetInterpolated(int frame) { var index = SortedFrames.BinarySearch(frame); if (index >= 0) return Data[index]; index = ~index; if (index == 0) return Data[index]; if (index >= Data.Count) return Data[Data.Count - 1]; return GetInterpolatedItem(frame, Data[index - 1], Data[index]); } protected abstract T GetInterpolatedItem(int …

24 c#  code-quality  complexity  code-reuse  dry 

考虑以下方法： public List<Employee> GetAllEmployees() { using (Entities entities = new Entities()) { return entities.Employees.ToList(); } } public List<Job> GetAllJobs() { using (Entities entities = new Entities()) { return entities.Jobs.ToList(); } } public List<Task> GetAllTasksOfTheJob(Job job) { using (Entities entities = new Entities()) { return entities.Tasks.Where(t => t.JobId == job.Id).ToList(); } …

23 c#  design-patterns  dry 

我正在构建REST API，以公开现有Java API的大部分功能。这两个API都供我的组织内部使用；我不必为外部使用而设计。我对这两种API都有影响，但是正在实现REST。Java API将继续用于本地应用程序（不会“淘汰”），但是REST API将用于重大的新开发。 一些Java API类只是数据（带有属性，getter，setter的bean）。并且至少其中一些有意义的是通过REST API以某种形式（作为数据（将被编组为XML或JSON））进行传输。例如，一个存储有关服务器计算机信息的类。对于这些数据类，我面临以下选择：我是否... 直接在REST API中公开原始Java类（或子类），或者 专门为REST API创建新的数据传输类（DTO模式）？ 无论哪种方式，我都会有REST数据传输类。问题是是要注释原始文件还是创建新的文件（可能是原始文件的副本）。可能还有其他选择，但我将主要关注这两个。 ＃1的参数： 干（不要重复自己） 实施更快 升级REST API更容易 ＃2的参数： 如果REST API需要与Java API分开版本，该怎么办？（这很有可能。） 如果Java数据类发生重大更改（例如，删除属性，添加行为或更改类层次结构）怎么办？（这也有可能。） 底线是，似乎在DRY（＃1）和去耦（＃2）之间进行了权衡。 我倾向于从＃1开始，然后如果出现问题，然后再转到＃2，请遵循不构建无法证明自己需要的敏捷指导。这是一个坏主意吗; 如果我认为我最终还是会从那里开始，我应该从＃2开始吗？ 我的清单中是否缺少主要的论据/后果？

19 java  api  rest  coupling  dry 

我在船上100％与1的情况应该 肯定使用了客户端和服务器端的数据验证。 但是，在我工作过的框架和环境中，我见过的方法从来都不是DRY。大多数情况下，没有计划或模式-验证写在模型规范中，而验证则写在视图上的表单中。（注意：我大部分的第一手经验是使用Rails，Sinatra和带有jQuery的PHP） 考虑一下，创建一个生成器似乎并不困难，只要生成一组验证（例如，模型名称，字段，条件），就可以生成必要的客户端和服务器端材料。或者，这种工具可以接受服务器端验证（例如validatesActiveRecord模型中的代码），并生成客户端验证（例如jQuery插件），然后将其应用于表单。 显然，以上只是“嘿，我有这个主意”，而不是正式的建议。这种事情肯定比这个主意击中时看起来要困难得多。 这使我想到一个问题：您将如何设计一种“一次写入，在服务器和客户端上运行”的数据验证技术？ 相关子主题：是否存在针对任何特定框架或客户端服务器技术的类似工具？尝试仅维护一组验证有哪些主要难题或挑战？

17 design  validation  dry  client-server 

我刚刚在维基百科上看到了文章“ 三法则 ” 第三规则是代码重构的经验法则，用于确定何时应将新代码替换为新过程。它指出该代码只能复制一次，但是当同一代码使用3次时，应将其提取到新过程中。该规则由Martin Fowler在“重构”中引入，并归因于Don Roberts。 我知道这只是一个经验法则，但是为什么建议仅在第二次重复之后才进行重构？编写第一个副本时，重构有什么不利之处吗？

16 refactoring  dry  rule-of-three 

验证函数输入参数的最佳位置在哪里：在调用方中还是在函数本身中？ 因为我想改善自己的编码风格，所以我尝试找到此问题的最佳实践或一些规则。何时何地更好。 在我以前的项目中，我们曾经检查并处理函数中的每个输入参数（例如，如果它不为null）。现在，我在这里已经在一些答案以及《实用程序员》一书中读到，输入参数的验证是调用者的责任。 因此，这意味着我应该在调用函数之前验证输入参数。调用该函数的任何地方。这就提出了一个问题：不是在调用函数的所有地方都产生了检查条件的重复吗？ 我对空条件不感兴趣，但对任何输入变量的验证（sqrt函数的负值，被零除，状态和邮政编码的错误组合或其他任何东西）都不感兴趣。 有一些规则如何决定在哪里检查输入条件？ 我在考虑一些争论： 当无效变量的处理方式可能有所不同时，最好在调用方进行验证（例如，sqrt()函数-在某些情况下，我可能想使用复数，因此我在调用方中处理条件） 当每个调用者的检查条件都相同时，最好在函数内部进行检查，以避免重复 调用方中输入参数的验证仅在使用此参数调用许多函数之前进行。因此，在每个函数中验证参数无效 正确的解决方案取决于具体情况 我希望这个问题不能与其他任何问题重复，我搜索了这个问题，发现了类似的问题，但是他们没有确切提及此案。

16 coding-standards  validation  dry 

假设我们有一个实现功能F的软件模块A。另一个模块B实现了与F'相同的功能。 有多种方法可以消除重复的代码： 让A使用B的F'。 让B使用A中的F。 将F放入自己的模块C中，让A和B都使用它。 所有这些选项都会在模块之间生成其他依赖关系。他们以增加耦合为代价应用了DRY原理。 据我所知，在应用DRY时，耦合总是增加或至少增加到更高的水平。软件设计的两个最基本的原则之间似乎存在冲突。 （实际上，这样的冲突并不令人惊讶。这可能是使良好的软件设计如此困难的原因。我确实感到惊讶的是，通常在介绍性文本中未解决这些冲突。） 编辑（为澄清起见）：我认为F和F'的相等不只是一个巧合。如果必须修改F，则很可能必须以相同的方式修改F'。

14 design  architecture  dry  coupling 

我正在寻找有关DRY与代码耦合的指南。我不喜欢复制代码，也不喜欢无关模块之间的代码耦合。因此，如果在引入重复项一年后发现完全相同的重复代码，我将重构重复代码。但是，我越来越多地体验到现实世界中更加难以预测的情况，并且在重构代码之后，出现了一些情况，需要再次分叉代码。 例如，如果我有处理汽油车，汽油SUV，电动汽车和电动SUV的代码，可以说我将重复的代码重构为“汽油”层次结构和“电动”层次结构，它们均从“车辆”层次结构中衍生而来。到目前为止，一切都很好。然后，我的公司推出了混合动力汽车和混合动力汽车Semi-需要对我的原始等级本身进行核心更改。可能需要在汽油和电气层次之间进行“组合”。 显然，代码重复是不好的，因为它增加了实现上述所有产品共有的更改所花费的时间。但是重构通用代码使引入产品特定的变体同样困难，并且当人们不得不找到代码行来修复错误时，会导致很多“类跳转”-上级父类中的一项更改可以触发所有后代之间的回归错误。 如何在DRY与有害代码耦合之间达到最佳平衡？

14 design  dry  coupling 

为了避免与C ++ const无关的重复，在某些情况下const_cast可以工作，但返回非const的私有const函数不起作用？ 在Scott Meyers的有效C ++项目3中，他建议将const_cast与静态强制转换结合使用可以是避免重复代码的有效且安全的方法，例如 const void* Bar::bar(int i) const { ... return variableResultingFromNonTrivialDotDotDotCode; } void* Bar::bar(int i) { return const_cast<void*>(static_cast<const Bar*>(this)->bar(i)); } Meyers继续解释说，让const函数调用非const函数是危险的。 下面的代码是一个反例，显示： 与Meyers的建议相反，有时将const_cast与静态强制转换结合使用是危险的 有时让const函数调用非const的危险性较小 有时两种使用const_cast的方式都可能隐藏有用的编译器错误 避免const_cast并让其他const私有成员返回非const是另一种选择 避免代码重复的const_cast策略中的一种是否被视为良好实践？您愿意使用私有方法策略吗？在某些情况下，const_cast可以工作，但私有方法不能工作吗？还有其他选择（除了重复）吗？ 我对const_cast策略的担心是，即使编写时代码正确，以后在维护期间代码也可能变得不正确，并且const_cast将隐藏有用的编译器错误。似乎普通的私有功能通常更安全。 class Foo { public: Foo(const LongLived& constLongLived, LongLived& mutableLongLived) : mConstLongLived(constLongLived), mMutableLongLived(mutableLongLived) {} // case A: we shouldn't …

14 c++  dry  const 

除了（ActiveRecord）模型外，我还始终在数据库级别应用约束。但是我一直在想这是否真的必要吗？ 一点背景 最近，我不得不对模型的基本自动时间戳生成方法进行单元测试。通常，测试会创建模型的实例并保存而不进行验证。但是表定义中还有其他必填字段不能为空，这意味着即使我跳过ActiveRecord验证，也无法保存实例。因此，我在考虑是否应该从数据库本身中删除此类约束，并让ORM处理它们？ 如果我跳过db，imo中的约束，可能的优点 - 可以修改模型中的验证规则，而不必迁移数据库。 可以跳过测试中的验证。 可能的缺点？ 如果可能ORM验证失败或被旁路，则数据库不会检查约束。 你怎么看？ 编辑在这种情况下，我使用的是Yii Framework，它从数据库生成模型，因此也生成了数据库规则（尽管我总是可以自己在生成后编写它们）。

13 database  orm  validation  dry