代码示例

我写的是关于设计的文章，我认为即使在讨论一些抽象的设计模式时，提供源代码示例也是很有用的。当然，这可能会导致人们认为代码示例就是模式，但我认为代码提供的精确性超过了这种风险。很多时候，我不太确定一个想法，但一个代码示例有助于我把它弄清楚。所以在我写设计的时候，我总是尽量提供代码示例。

代码示例有很多种方式。许多读者喜欢完整的示例，展示多个想法是如何相互关联的。我采取了不同的路线。我更喜欢非常小的、重点突出的示例，每次只展示一个想法。

展示多个概念的现实示例的问题在于，它们很难理解，因为你必须理解所有概念才能理解示例。而使用重点突出的示例，您可以只关注一件事。然而，使用重点突出的示例，您无法看到这些概念是如何组合在一起的。理想情况下，您应该同时提供重点突出的示例来解释各个部分，并提供相互关联的示例来展示它们是如何组合在一起的。我承认我没有精力同时做这两件事，所以我只展示重点突出的示例。我的理由是，一旦人们掌握了基本模式，他们就能更容易地将示例组合在一起。此外，其他作者可以以我的内容为基础，提供相互关联的示例。(相互关联的示例更难一些，因为我喜欢展示替代模式，所以这会导致在更大的示例中需要展示更多的互连组合。)

重点突出示例的技巧之一是将注意力集中在示例的要点上。所以我做的一件事就是保持其他一切简单明了，这意味着如果其他模式可能会影响对核心问题的理解，我就会避免使用它们，即使您会在真实的系统中使用这些模式。这方面的一个例子是P of EAA中的对象关系映射模式。我展示了许多映射模式（例如外键映射），其中我对对象和数据库之间的数据传输进行了硬编码。但在许多现实系统中（当然在 OR 工具中），您不会对这些传输进行硬编码，而是会使用元数据映射。我将它们显示为硬编码传输，因为我认为这更容易理解发生了什么，并且还允许您在不了解元数据映射的情况下理解外键映射。

保持简单性的另一个结果是忽略了在实际代码中应该进行错误处理的边缘情况。我对这一点感到有点尴尬，在保持示例代码简单和确保示例代码展示良好习惯之间存在着一种张力。

这与我为什么不提供代码示例下载有关。我避免下载是因为我使用的代码示例在模式之外的区域包含了大量的字符串和胶带。比如从静态字段生成插入的 ID——在真实的系统中你绝对不能这样做。我这样做是因为它对我的简单示例来说更容易，而且我在书中没有向人们展示脚手架。

下载代码也偏离了重点。代码示例的重点是代码所表达的思想，而不是代码本身。您必须阅读它才能理解，而不能仅仅把它扔到您自己的应用程序中。代码下载的一个优点是，您可以逐步执行它，以帮助理解它是如何工作的。这是一个合理的观点，但胶带却破坏了这种效果。我认为下载的示例更适用于相互关联的示例，而不是重点突出的示例。