程式碼範例

我寫設計，我的觀點是，即使在討論抽象的設計模式時，提供原始碼範例也很有幫助。當然，這可能會讓人認為程式碼範例就是模式，但我認為程式碼提供的精確性大於這種風險。有幾次我對一個想法不太確定，但程式碼範例有助於我釐清它。因此，在我關於設計的寫作中，我總是試著提供程式碼範例。

有幾種提供程式碼範例的方式。許多讀者喜歡完整的範例，展示多個想法如何相互連結。我採取不同的路線。我比較喜歡非常小且專注的範例，一次只展示一個想法。

展示多個概念的實際範例的問題在於，它們很難理解，因為你必須理解所有概念才能理解範例。有了專注的範例，你只能專注於一件事。然而，有了專注的範例，你無法看到概念如何組合在一起。理想情況下，你應該同時提供專注的範例以了解各個部分，以及互連的範例以展示它們如何組合在一起。我承認我沒有精力同時做到這兩件事，所以我只展示專注的範例。我的理由是，一旦人們掌握了基本模式，他們就能更容易地組合範例。此外，其他作者可以建立在我的東西上，並提供互連的範例。（互連的範例更難一步，因為我喜歡展示替代模式，因此會導致更大的範例中需要展示更多互連組合。）

專注範例的技巧之一是將注意力放在範例的重點上。因此，我所做的事情之一就是讓其他一切都保持簡單且不礙事，這表示我避免使用其他模式，如果它們可能會模糊對核心問題的理解，即使你會在真實系統中使用這些模式。EAA 的 P 中的物件關係對應模式就是一個例子。我展示了很多對應模式（例如外來鍵對應），我在其中對物件和資料庫之間的資料傳輸進行硬編碼。但在許多實際系統（當然也在 OR 工具中），你不會對這些傳輸進行硬編碼，而是會使用元資料對應。我將它們展示為硬編碼傳輸，因為我認為這樣可以更容易理解正在發生的事情，並且還可以讓你了解外來鍵對應，而無需了解元資料對應。

保持簡單的另一個後果是忽略邊界情況，而邊界情況應該在實際程式碼中進行錯誤處理。我對此感到有點尷尬，在保持範例程式碼簡單和確保範例程式碼顯示良好習慣之間存在著緊張關係。

這與我不提供可供下載的程式碼範例的原因有關。我避免下載，因為我使用的程式碼範例包含許多字串和在模式之外區域的膠帶。例如從靜態欄位產生插入的 ID，這是您在實際系統中絕對不能做的。我這樣做是因為這對我的簡單範例來說比較容易，而且我不會在書中向人們展示鷹架。

下載程式碼也會錯失重點。程式碼範例的重點在於程式碼所表達的想法，而不是程式碼本身。您必須閱讀才能理解，您不能只將它丟到您自己的應用程式中。程式碼下載的一個優點是您可以逐步執行它，以幫助了解它的運作方式。這是一個有效的觀點，但膠帶會破壞這種效果。我認為下載的範例對於互連範例比對於焦點範例更有效。