什么时候召集四人组？ [什么时候使用设计模式？]

Posted 2023-02-16

【中文标题】什么时候召集四人组？ [什么时候使用设计模式？]

【英文标题】：When to call the gang of four? [When to use design patterns?]

【发布时间】：2010-09-20 18:30:52

【问题描述】：

在The Guerilla Guide to Interviewing Joel 中说，想要完成任务但不聪明的人会做一些愚蠢的事情，比如使用访问者设计模式，而简单的数组就足够了。

如果应该应用Gang of Four 建议的设计模式，我发现很难检测。

因此，我想从你的工作经历中获得一些例子

什么时候简单的方法（固定大小的数组）就足够了？ 证明使用 GoF 模式的软件的最小大小是多少？ 何时从头脑简单重构为 GoF？这可以以一种明智的方式完成吗？

【参考方案1】：

设计模式是结果，而不是目标。你不认为今天我会使用策略模式，你就去做吧。在完成第三个几乎相同的课程的中途，您停下来使用纸质笔记本找出一般情况并敲出一个描述共享上下文的基类。您将前两个类重构为后代，这使您可以进行现实检查，并对基类进行很多更改。然后接下来的三十个是在公园里散步。

只有在第二天的团队会议上，您才可以通过说“我使用策略模式。它们都工作相同，所以只有一个测试程序，它需要参数来更改测试用例”，从而为大家节省了 30 分钟的无聊时间。

对模式的深入了解使您能够在情况需要时反射性地使用它们。当人们将模式的使用本身视为一个目标时，你会得到生硬、丑陋的代码，它谈论的是机制而不是目的；如何而不是为什么。

---

大多数模式都解决了反复出现的基本问题，例如降低复杂性和需要提供可扩展点。在明确不需要它们的情况下提供可扩展点会使您的代码无意义地复杂化并创建更多故障点和测试用例。除非您正在构建一个发布到野外的框架，否则只解决您实际面临的问题。

【讨论】：

策略模式的简单解释！

【参考方案2】：

GoF 原书的一大优点是讨论了该模式最能解决问题的场景。查看这些讨论可以帮助您确定“是时候”了。

另一个好的起点是Head First Design Patterns。说明使用不同设计模式的练习非常详尽，足以提供良好的学习体验。此外，这些练习还以现实世界的场景为基础，因此可以毫不费力地确定何时应用设计模式的适当时机。

【参考方案3】：

模式只是工具和词汇。您编写的代码尽可能简单、易于理解和可维护。通过了解模式，您可以使用更多替代方案，并且您有一种语言可以在实施之前讨论该方法的优缺点。

在任何一种情况下，您都不只是“切换”到“使用模式”。你只是继续做你一直在做的事情，用你知道的最好的方式编写代码。

【参考方案4】：

当您遇到某个模式可以解决的问题时。 GoF 书的每一章都有一节解释每种模式适用于哪些类型的场景。你应该不分析你遇到的每个问题，然后去查找要使用的模式。您应该熟悉这些模式，以便学会识别需要它们的情况。

【参考方案5】：

随着问题的复杂性增加，从简单的方法切换到正式的设计模式对我来说通常是很自然的事情。关键是要足够熟悉模式，以便您可以识别临界点并从简单的方法切换到设计模式，因为它会为当前和未来的开发带来最大的好处。

对于一个更大、更复杂的项目，临界点应该在相当早的时候；在许多情况下，甚至在您开始编码之前。对于较小的项目，您可以在决定实施模式之前等待。

您可以做的最好的事情之一是提高您识别何时应该使用模式的能力，即在完成项目后花一些时间来检查您的“简单”方法变得多么复杂。如果实现一个模式会花费您更少的时间和精力，或者如果该模式能够阐明您想要做什么，那么您可以将这些知识归档以备下次遇到类似问题时使用。

【参考方案6】：

我经常发现，在遇到这些问题时，使用测试驱动开发有助于指导我。

什么时候是一个简单的方法 足够了吗？ 总是足够的 用最简单的方法得到 下一个测试要通过。但知道 何时/如何重构才是真正的艺术 形式。 最小尺寸是多少 一个软件，它证明了 使用 GoF 模式？ 我曾经读过的拇指是，当你 编码一次，很好，当你 在某处复制该代码 第二次，记下并移动 在。当你发现需要 第三次相同的代码，是时候 重构以删除重复和 简化，通常涉及 转向设计模式。 什么时候 从头脑简单的重构到 GoF？ 我喜欢@anopres 所说的 - 它是 当你感到痛苦的时候 设计模式到位。 疼痛（或代码“气味”）可能 体现在几个方面。 代码重复是最多的 明显的。重构书籍，例如 福勒的Refactoring 或 Kerievsky 的Refactoring to Patterns 列出了许多这样的痛苦 点/代码恶臭。 这个可以吗 [重构] 明智地进行 方式？ 重构的诀窍是 有一套单元测试到位 你有信心的，和 然后重构而不引起任何 这些测试失败。 根据定义，重构不会 改变你的功能 代码。因此，如果您的测试 继续通过，你可以拥有一个 很好的感觉，你没有 打破任何东西。虽然这可能很困难，但我真的很喜欢 TDD 的这一部分，它几乎就像一个在不破坏任何测试的情况下进行更改的游戏。

总而言之，我想说的是，TDD 帮助指导我编写当时足够的代码，也许更重要的是帮助我在以后不可避免的需求变化、需要更多功能等时进行更改。

【参考方案7】：

这类似于任何其他设计决策。最终，这取决于。您应该学习那些对您的语言有用的模式（例如，Lisp 或 Smalltalk 中不需要许多 GoF 模式），了解它们的优缺点，了解系统的限制，并做出最适合您需求的选择.

我能给出的最好建议是学习、学习、再学习。

【讨论】：

没有多少已发布的产品是用 Lisp 或 Smalltalk 构建的，我认为这可能是因为虽然 C 是低级的，但它可以通过明智地使用模式来实现高级设计。因此，您的工具与情况需要一样高或低。另一方面是对开发人员理解和技能的要求。是的，七年来我一直在考虑你的答案。 :)

我认为使用 Lisp 或 Smalltalk 的产品并不多，因为当微型计算机革命发生时，程序员的数量激增，而早期的微型计算机上只有低级语言是实用的。因此，即使在微型计算机可以做更多事情之后，新程序员都习惯了低级语言。微型计算机编程文化花了 30 年时间才用 Perl、Python、Ruby 和 javascript 等语言几乎赶上了 Lisp 和 Smalltalk。公平地说，我这样说的人用 C 编写的生产代码比用 Lisp 和 Smalltalk 加起来还要多。

此外，C 的设计非常出色。数据结构中的函数指针可以提供很多面向对象编程。我相信 Unix 设备驱动系统，主要设备号选择驱动程序（程序集）和次要设备号选择设备（特定状态集合）是面向对象编程的早期示例。驱动程序是类，设备是对象。这是通过将函数指针存储在结构中来实现的。我很荣幸你发现我的帖子如此发人深省！