对相似的功能使用不同的模式

我是该项目的唯一开发人员，就像其他软件项目一样，将来可能会被其他人采用。

假设我使用模式X来实现功能A。在开发和完成功能之后，我意识到可以使用我刚刚学习的模式Y来实现相同的功能。但是功能A运行良好，并且从X到Y的重构既耗时又无济于事。

然后是实现功能B的时候了。它与A相似，但是这次我想借此机会使用模式Y。我对最终结果感到满意，比使用功能A更好，但是现在我的代码使用了两个具有相似特征的X和Y不同的图案。

但是没有真正的理由使用不同的模式，除了以下事实：构建功能AI的技能不足以使用与功能B相同的模式。

请注意，此问题不是针对给定问题选择正确的模式；这是在代码库中共存的两种模式，用于解决类似的问题，如果有足够的时间进行重构，则可以将其减少为一种。

• 该代码闻到了吗？
• 保持这样的源代码有什么缺点？
• 我应该只使用一种模式吗？即重构A以使用Y或在编写B时继续使用X？
• 从源头上，我该如何传达出针对相似功能存在两种不同模式的原因基本上是没有原因的？
• 我是否担心下一位开发人员对我的代码的看法？

如果模式X和Y解决了相同的问题，并且客观上都不是更好，那么您应该选择一个并坚持下去。如果有可能，您应该努力以相同的方式始终如一地解决相同的问题。

你是不是过虑，而这是一个严重的代码味道，你一定要处理和清理。

在代码库中对同一问题具有不同解决方案的缺点：

• 理解代码需要花费两倍的时间
• 当您更改某些涉及模式的行为时，修改代码的时间将是原来的两倍
• 您将有两倍的错误
• 现在和将来的同事都会讨厌你

我同意JacquesB的回答。我想加起来，解决您的其他问题，如果现在您有两种模式并存，并且还没有时间（尚未）重构您的应用程序以使用您认为最好的一种模式，在您的“令人反感”类（将要重构的类）中添加注释。这样，对于将来的开发人员（您或其他人）来说，仍然有一些债务需要偿还。

最后，维护这样的代码库的主要缺点是增加了不必要的复杂性。您绝对想不惜一切代价避免不必要的复杂性！

不要在代码库中玩。编写原型可以使您发现一种模式/设计相对于另一种模式的优势和劣势。

可能会发现，可以直观地减少的感觉实际上可能比具有2种不同的模式更为复杂。

期望抛出一种为原型开发的大部分代码。

这是否是代码异味实际上取决于问题A和问题B的相似程度。JacquesB的答案似乎假设它们非常相似，并且，如果您更改问题A（例如，修复错误），您还必须同时更改问题B。JaqueB可能是正确的，但也可能是A和B独立更改的情况，因为它们并不完全相同。在这种情况下，您不太可能描述其缺点。

根据您的描述，听起来好像有点代码气味（重复），但是很难分辨出气味是多么的臭。例如，如果A使用模板方法而B使用策略，则尽管使用了镜像模式，但两个问题可能会非常不同。我将拭目以待。如果出现问题C，就像A和B，那么我将A重构为与B一致，然后创建C应该非常简单。如果A中存在一个错误，我也想对其进行重构以使其与B匹配，然后修复该错误。如果没有任何变化，那么...没有关系吗？

解决代码库中类似问题的多种方法已成事实。即使在您是唯一的开发人员的情况下，您也将学习新事物并获得新见解，因此您的解决方案将发生变化。正确认识到您需要在提供价值的同时修复这些缺陷。重新设计（这是更改模式时您实际上正在做的事情），再也不会更改的代码无法提供价值。知道将要更改的唯一真实方法是实际上必须进行更改，这就是为什么我要等待问题C的原因。

不，您可以在一个代码库中使用多个模式。

但是，如果您要实现一个组件，并且要公开一种遵循某种模式的使用方式，那么最好还是坚持下去。举例来说，我为REST查询客户端使用了构建器模式，但是随后我以不同的方式实现了其中一种资源。这会让人们感到困惑。