<!-- The Pattern Concept --> ## 概念 最初，你可以將模式視為解決特定類問題的一種特別巧妙且有深刻見解的方法。這就像前輩已經從所有角度去解決問題，并提出了最通用，最靈活的解決方案。問題可能是你之前看到并解決過的問題，但你的解決方案可能沒有你在模式中體現的那種完整性。 雖然它們被稱為“設計模式”，但它們實際上并不與設計領域相關聯。模式似乎與傳統的分析、設計和實現的思維方式不同。相反，模式在程序中體現了一個完整的思想，因此它有時會出現在分析階段或高級設計階段。因為模式在代碼中有一個直接的實現，所以你可能不會期望模式在低級設計或實現之前出現(而且通常在到達這些階段之前，你不會意識到需要一個特定的模式)。 模式的基本概念也可以看作是程序設計的基本概念:添加抽象層。當你抽象一些東西的時候，就像在剝離特定的細節，而這背后最重要的動機之一是: > **將易變的事物與不變的事物分開** 另一種方法是，一旦你發現程序的某些部分可能因某種原因而發生變化，你要保持這些變化不會引起整個代碼中其他變化。 如果代碼更容易理解，那么維護起來會更容易。 通常，開發一個優雅且易維護設計中最困難的部分是發現我稱之為變化的載體（也就是最易改變的地方）。這意味著找到系統中最重要的變化，換而言之，找到變化會導致最嚴重后果的地方。一旦發現變化載體，就可以圍繞構建設計的焦點。 因此，設計模式的目標是隔離代碼中的更改。 如果以這種方式去看，你已經在本書中看到了設計模式。 例如，繼承可以被認為是一種設計模式（雖然是由編譯器實現的）。它允許你表達所有具有相同接口的對象（即保持相同的行為）中的行為差異（這就是變化的部分）。組合也可以被視為一種模式，因為它允許你動態或靜態地更改實現類的對象，從而改變類的工作方式。 你還看到了設計模式中出現的另一種模式：迭代器（Java 1.0和1.1隨意地將其稱為枚舉; Java 2 集合才使用Iterator）。當你逐個選擇元素時并逐步處理，這會隱藏集合的特定實現。迭代器允許你編寫通用代碼，該代碼對序列中的所有元素執行操作，而不考慮序列的構建方式。因此，你的通用代碼可以與任何可以生成迭代器的集合一起使用。 即使模式是非常有用的，但有些人斷言： > **設計模式代表語言的失敗。** 這是一個非常重要的見解，因為一個模式在 C++ 有意義，可能在JAVA或者其他語言中就沒有意義。出于這個原因，所以一個模式可能出現在設計模式書上，不意味著應用于你的編程語言是有用的。 我認為“語言失敗”這個觀點是有道理的，但是我也認為這個觀點過于簡單化。如果你試圖解決一個特定的問題，而你使用的語言沒有直接提供支持你使用的技巧，你可以說這個是語言的失敗。但是，你使用特定的技巧的頻率的是多少呢？也許平衡是對的：當你使用特定的技巧的時候，你必須付出更多的努力，但是你又沒有足夠的理由去使得語言支持這個技術。另一方面，沒有語言的支持，使用這種技術常常會很混亂，但是在語言支持下，你可能會改變編程方式（例如，Java 8流實現此目的）。