模式，最佳实践和清洁代码

Question

我经常发现自己正在阅读书籍和文章，概述模式，最佳实践以及如何编写“干净的代码”。然而，其中一些概念似乎过于设计，有时模糊了底层问题的本质，使得代码更难以与被建模的问题域相关联。

您多久发现自己重构一段能够支持“模式”的代码？您是否遇到过“模式”实际上使代码复杂化或模糊其含义的情况？在看到一个问题的解决方案后，我用一个简单的类使用lambdas和闭包重写了一段时间后我感觉到了这种方式。

我很挣扎，我很好奇其他人如何找到合适的平衡点。

Answer 1

你永远不应该重构你的代码，只是为了使它适合你在某本书中读过的模式。

模式真的可以帮助您在思考良好的软件设计方面训练您的大脑。我实际上会说，通过阅读模式书并反思它们并学习理解它们如何运作以及它们会给你带来什么好处，我获得了很多编程技巧和知识。这实际上是关键。他们的目的是让事情变得更容易，更易于维护，更容易测试等等......不要让你的生活更加艰难：）

我认为这也是“困难”。模式为您提供一个框架，一个从遇到问题时开始的点。示例：您确实希望对代码进行单元测试，但是您无法进行单元测试，因为它依赖于UI逻辑或者耦合太多。这是你的问题，所以你可以通过了解MVC模式以及依赖注入和IOC的概念来获得解决方案。他们可能会给你一个起点，因为MVC例如解释了Observer，Observable，Controller视图等的高级概念......以及它们如何相互关联。然后，作为一名优秀的程序员，您可以选择正确的方法，以及您认为应用该模式的合理范围。不要只是应用它，因为模式告诉你。请记住，它只是一个框架，您可以修改和调整它。它适合您的具体情况。

Answer 2

我的建议是尽可能保持您的设计直截了当 - 而不牺牲可维护性。

基于良好模式的面向对象设计有许多小的，非常专业的类。最简单的功能可以触及许多类。这使得学习/理解设计变得耗费时间。这种“良好因素”的优点是代码是可维护的 - 一个小的需求变化通常需要一个小的本地化代码更改。

您的系统越不复杂，您就越容易通过简单的设计逃脱。但随着系统变得越来越大，越来越复杂，为了可维护性，这种权衡转向更复杂的设计。

Answer 3

使用这些文章和书籍作为指南。您知道的越多，您就可以在做出正确决定使用什么和什么时候做出正确的决定。设计模式并不意味着尽可能使用，也不是重构你刚刚做的事情。

您应该在需要时重构代码。例如，当您添加功能或修复错误并注意到可以使其更好。

您应该以相同的方式使用模式。当使用错误/不正确时，模式会使代码变得更糟，并且当更简单的非模式方式满足解决方案时，模式会使代码模糊。没有必要在代码中使用模式快乐，当发生这种情况时，代码就更糟糕了。

坚持YAGNI（你不需要它）的方法。这并不是说，你永远不会考虑你的设计。相反，我们经常提到的是，我们经常会过度设计我们的解决方案，而不是随着时间的推移随着需求的确定而发展。

  

“理论是好的。理论提醒我们   人们已经处理过这些问题   之前的问题。但这是法律吗？我们欠   它是我们自己思考和   了解自己。“    - Rob Conery

Answer 4

我认为问题的一部分是书中的例子。

当你写一本书或一篇文章时，你需要一些例子来表达你的想法。通常这些例子都很简单。然而，对于一个简单的例子，“模式”可能没有多大意义。

然后有些人开始将复杂的机器应用于各种简单的问题，只是为了在某个地方贴上一个模式。我认为这是你所描述的模式的糟糕用法。

然而，对于更复杂的设计（好吧，它需要非常良好的判断）模式可能是有用的。您可能还想阅读When are design patterns the problem instead of the solution?

Answer 5

如果不挥杆，你就不能击球。为了找到合适的平衡点，您需要进行实验，这意味着您有时可能会过度使用。当你认为另一种设计能够更好地工作时，你不应该害怕尝试新事物和重构。你应该害怕的唯一不是学习和变得更好。

Answer 6

IIABDFI。如果它没有被破坏，请不要修复它。

换句话说，唯一的理由重新编写“一段运行良好的代码”，如果您需要概括它不会使相同的代码重新可用的。

在这种情况下，使用模式可以有效地确定如何有效地实现可重用性，但模式需要是工具，而不是最终目标。

请注意，无论是否使用模式都是一个完全不同的问题，我发现最好的答案是this SO question的第一个（接受的）答案。简而言之，如果您是一名优秀的开发人员，无论您是否了解它，您都将使用模式，因为所有模式都是针对特定类设计问题的常见解决方案。 （我在那种情况下 - 多年来创造或被教导，并且反复使用，可能有用的设计只被告知有一天这些东西被称为模式而有人给了他们可爱的名字。）

Answer 7

实际上，就在最近我在推特上发了一个论点。我邀请了一些程序员“设计模式barcamp”。但是有一个人开始说在这样的营地里没有任何意义，因为你是否知道模式或不知道。他说，这就像达到了必杀技。但我不同意。我们都是工程师。并且学习如何编写好的软件，部分来自抽象。但是，这还不够。学习其他编程语言，范例，扩展您正在使用的工具的知识，阅读用您最喜欢的语言编写的开源软件的代码，您将成为一个更好的程序员（如果你有幸的话）< / p>

回答你的问题。是的，有些人认为他们可以应用模式。但有时他们会采取不适合他们问题的模式。我想说所有工具都是最适合他们的目的。所以，模式是一样的。如果您不确定，请更好地与您的建筑师交谈。查看最佳实践是什么，为什么使用模式，它会给出什么样的可能性/困难？这不是开销吗？代码仍然可读和可支持吗？如果“是”，那么请继续。

Answer 8

大多数时候，我发现效果良好的代码已经遵循了适当的模式。 我看到有两种模式有复杂的东西 - Singleton和Decorator。 恕我直言，Singleton只是一类静态方法的更详细版本。装饰器模式也不是很好，因为它迫使每个装饰器重新实施一个违反DRY的锅炉板负载，以及了解违反SRP的装饰。 总的来说，模式大多是很好的工具，但仅仅因为一个概念的标题是＆＃34;模式＆＃34;并不意味着它有任何好处。