物件導向程式由物件組成，物件包括資料和對資料進行操作的過程，過程通常稱為方法或操作。
物件在收到客戶的請求（或訊息）後，執行相應的操作。
客戶請求是使物件執行操作的唯一方法，操作又是物件改變內部資料的唯一方法。
由於這些限制，物件的內部狀態是被封裝的，它不能被直接訪問，它的表示對於物件外部是不可見的。
物件導向設計最困難的部分是將系統分解成物件集合。
因為要考慮許多因素：封裝、粒度、依賴關係、靈活性、效能、演化、復用等，它們都影響著系統的分解，並且這些因素通常還是互相衝突的。
設計的許多物件**於現實世界的分析模型。但是，設計結果所得到的類通常在現實世界中並不存在，有些是像陣列之類的低層類，而另一些則層次較高。
設計模式幫你確定並不明顯的抽象和描述這些抽象的物件。例如，描述過程或演算法的物件現實中並不存在，但它們卻是設計的關鍵部分。
物件在大小和數目上的變化極大。它們能表示下自硬體或上自整個應用的任何事物。
那麼我們怎麼決定乙個物件應該是什麼呢？設計模式很好地講述了這個問題。
facade 模式描述了怎樣用物件表示完整的子系統。
flyweight 模式描述了如何支援大量的最小粒度的物件。
其他一些設計模式描述了將乙個物件分解成許多小物件的特定方法。
abstract factory 和 builder 模式產生那些專門負責生成其他物件的物件。
visitor 和 command 生成的物件專門負責實現對其他物件或物件組的請求。
物件宣告的每乙個操作指定操作名、作為引數的物件和返回值，這就是所謂的操作的型構（signature）。
物件操作所定義的所有操作型構的集合被稱為該物件的介面（inte***ce）。
物件介面描述了該物件所能接受的全部請求的集合，任何匹配物件介面中型構的請求都可以傳送給該物件。
設計模式通過確定介面的主要組成成分及經介面傳送的資料型別，來幫助你定義介面。
設計模式指定了介面之間的關係。它們經常要求一些類具有相似的介面，或它們對一些類的介面做了限制。
型別（type）是用來標識特定介面的乙個名字。
當乙個型別的介面包含另乙個型別的介面時，我們就說它是另乙個型別的子型別（subtype），另乙個型別稱之為它的超型別（supertype）。
我們常說子型別繼承了它的超型別的介面。
在物件導向系統中，介面時基本的組成部分。物件只有通過它們的介面才能與外部交流。
物件介面與其功能實現是分離的，不同物件可以對請求做不同的實現。
多型（polymorphism）
當給物件傳送請求時，所引起的具體操作既與請求本身有關又與接受物件有關。
支援相同請求的不同物件可能對請求激發的操作有不同的實現。
傳送給物件的請求和它的相應操作在執行時刻的連線就稱之為動態繫結（dynamic binding）。
動態繫結是指傳送的請求知道執行時刻才受你的具體的實現的約束。
動態繫結允許你在執行時刻彼此替換有相同介面的物件。這種可替換性就稱為多型（polymorphism）。
多型允許客戶物件僅要求其他物件支援特定的介面，除此之外對其假設幾近於無。
物件通過例項化類來建立，此物件被稱為該類的例項。
抽象類（abstract class）的主要目的是為它的子類定義公共介面。
乙個抽象類將把它的部分或全部操作的實現延遲到子類中，因此，乙個抽象類不能被例項化。
子類能夠重定義（override）父類定義的操作，重定義使得子類能接管父類對請求的處理操作。
類繼承允許你只需簡單的擴充套件其他類就可以定義新類，從而可以很容易地定義具有相近功能的物件族。
類繼承根據乙個物件的實現定義了另乙個物件的實現。簡而言之，它是**和表示的共享機制。
介面繼承（或子型別化）描述了乙個物件什麼時候能被用來替代另乙個物件。
儘管大部分程式語言並不區分類繼承和介面繼承，但使用中人們還是分別對待它們的。
物件導向的設計原則：針對介面程式設計，而不是針對實現程式設計。
物件導向系統中功能復用的兩種最常用技術室類繼承和物件組合（object composition）。
類繼承允許你根據其他類的實現來定義乙個類的實現。這種通過生成子類的復用通常被稱為白箱復用（white-box reuse）。
新的更複雜的功能可以通過組裝或組合物件來獲得。這種復用風格被稱為黑箱復用（black-box reuse）。因為物件的內部細節是不可見的。
父類通常至少定義了部分子類的具體表示。因此繼承對子類揭示了其父類的實現細節，所以繼承常被認為「破壞了封裝性」。
乙個可用的解決方法就是只繼承抽象類，因為抽象類通常提供較少的實現。
物件組合是通過獲得對其他物件的引用而在執行時刻動態定義的。組合要求物件遵守彼此的介面約定，進而要求更仔細地定義介面。
因為物件只能通過介面訪問，所以我們並不破壞封裝性。
使用物件組合有助於保持每個類被封裝並被集中在單個任務上，這樣類和類繼承層次會保持較小規模。
物件導向的設計原則：優先使用物件組合，而不是類繼承。
**不可能揭示關於系統如何工作的全部，系統的執行時結構更多地受到設計者的影響，而不是程式語言。
物件和它們的型別之間的關係必須更加仔細的設計，因為它們決定了執行時程式結構的好壞。
許多設計模式顯式地記述了編譯時和執行時結構的差別。
composite 和 decorator 對於構造複雜的執行時結構特別有用。
observer 也與執行時結構有關。
chain of responsibility 也產生了繼承所無法展現的通訊模式。
獲得最大限度復用的關鍵在於對新需求和已有需求發生變化時的預見性，要求你的系統設計要能夠相應的改進。
乙個不考慮系統變化的設計在將來就有可能需要重新設計。
設計模式可以確保系統能以特定方式變化，從而幫助你避免重新設計系統。
《設計模式》學習筆記 設計模式怎樣解決設計問題
1.1 設計模式怎樣解決設計問題 1.1.1 尋找合適的物件 物件導向設計最困難的部分是將系統分解為物件的集合。設計的許多物件 於現實世界的分析模型，這裡和領域驅動設計有點關聯。分析所得到的類，很多事現實中並不存在的類。這是抽象的結果。設計中的抽象對於產生靈活的設計至關重要。就像我設計的乙個流程排程...
《設計模式》學習筆記 設計模式怎樣解決設計問題
1.1 設計模式怎樣解決設計問題 1.1.1 尋找合適的物件 物件導向設計最困難的部分是將系統分解為物件的集合。設計的許多物件 於現實世界的分析模型，這裡和領域驅動設計有點關聯。分析所得到的類，很多事現實中並不存在的類。這是抽象的結果。設計中的抽象對於產生靈活的設計至關重要。就像我設計的乙個流程排程...
設計模式怎樣解決設計問題 1 尋找合適的物件
設計模式怎樣解決設計問題 1 尋找合適的物件 物件導向設計最困難的部分是將系統分解成物件集合。因為要考慮許多因素 封裝 依賴關係 靈活性 效能 演化 復用等等，它們都影響著系統的分解，並且這些因素通常都是互相衝突的。尋找合適的類是為了便於你設計出好用的類，包含了3種設計模式 composite模式 ...