术语“设计模式”是一个负担过重和混淆的术语。
有一种狭义的理解方式：基本上作为GoF书中列出的面向对象概念的集合的统称，例如Singleton、Facade、Strategy等。如果您在简历上将设计模式作为一项能力，则可能使用此定义。
一个项目很容易包含数十个单例对象。这种模式显然受益于被编码为可实例化的抽象，例如作为宏或抽象类。对于GoF书中的许多其他模式也是如此。
在我看来，Paul Graham的论点是：设计模式作为重复自己的标准方式，应该被编码为可实例化的抽象，并且由此推论，您应该使用具有非常灵活的定义可实例化抽象的语言。
但是，这个概念更加普遍——我认为他曲解了设计模式。Christopher Alexander发明了这个概念，以便将其应用于国家、城市、城镇和房屋的设计。游戏设计师有像战争迷雾、不对称能力等模式的语言。
在这个普遍意义上，设计模式是否都应该被编码为可实例化的抽象就不那么明显了。
如果您还没有阅读《模式语言》，请查看其范围
here。想象一下这样的东西适用于软件世界。GoF模式将位于目录底部：它们是实现细节。
您还能找到哪些其他模式？
我猜一个章节会有与游戏相关的模式。它可以包含游戏设计模式和实现技术，——我认为这不是一个明确的区别——例如游戏循环、世界实体、空间哈希、高度图景等等。这些都是设计模式。
现在，在一个游戏项目的范围内，您可能只有一个世界实体实现。任何使用任何语言的人都会意识到，将此世界实体作为基类的可实例化抽象。
但是，这个模式描述的是如何形成这个抽象：它包含一些位置概念，它是可渲染的等等。这个设计模式是否受益于被编码为宏或抽象类本身并不明显！这个模式已经描述了一个抽象！您会为世界实体实现创建元类吗？使用各种难以置信的参数定义世界实体类的宏？
在想象中的目录中继续向上查看，我们看到这些模式是次要的，比较通用的模式，即游戏模式。这是否值得编码为宏或抽象类？也许。但不明显。我们谈论的是一个游戏框架，在其中通过传递参数、填写空白等方式定义计算机游戏。这可能很有成效和有趣，但这并不是唯一的方法。
Erlang平台具有可实例化的抽象模式，涵盖各种通用类型，例如服务器，这很酷。我猜Erlang项目中的服务器数量与Java项目中单例的数量相同。
但是对于特定目的，如果您使用Lisp、Haskell或其他语言编写服务器，有时只需遵循服务器模式，在函数和对象中实现它，而不必尝试将其作为整个实例化抽象。
所有设计模式并非在源代码中呈现为低层文本模式。
