C++

（根據MSDN Webcast 相關課程整理）直接與間接： 對於複雜的系統，我們常常在使用時添加一個中介層，從而屏蔽一些不常用的功能，或簡化一些常用功能等，從而達到用簡單靈活的方法滿足特定的需要的目的。 如：A訪問B時，每訪問一次B，就需要調用一次B對象，由於B對象的複雜性，調用開銷較大，尤其是B處於分布式應用當中時。另一方面，直接調用複雜的對象，暴露了過多的A不需要的介面，造成不安全性。 加是中介層C以後，簡化了B的介面與複雜性，使得A對C的訪問簡單靈活安全，

（根據MSDN WebCast相關課程整理）變化是軟體設計中永恒的主題，如何管理變化帶來的複雜性？設計模式的藝術性與複雜度就在於如何分析並發現系統中的變化點和穩定點，並使用特定的設計方法來應對這種變化。 事件架構穩定，而子步驟經常改變。 GoF：定義一個操作中的演算法的架構，而將一些步驟延遲到子類中，Template Method使用是子類可以不改變一個演算法的結構即可以重定義該演算法的某些特定步驟。

（根據MSDN WebCast相關課程整理）實體物件與行為操作之間往往也存在耦合關係。 行為要求者通過“命令”行為實現者去執行一定的行為。 GoF：將請求封裝成一個對象，從而使我們可用不同的請求對客戶程式進行參數化操作，以及對請求排隊或記錄講求日誌，以及支援可撤銷的操作。 把ClientProgram對Receive.Action()的緊耦合的調用，變為對具體命令對象(ConcreteCommand對象)的調用，從而實現對多變的行為的有效管理。

（根據MSDN Webcast相關課程整理） 由俄羅斯套娃講起。娃娃裡又包含另一個娃娃，最後那個不包含任何娃娃。 組合模式，採用樹型結構來實現普遍存在的對象容器，將本原一對多的複雜的關係，轉換成一對一的簡單關係，從而可以一致的處理一批對象，使得客戶程式不需要關心對象內容的具體實現。 將客戶程式與對象內部實現解耦，是組合模式的核心思想。解耦後，客戶程式只能對象上層的介面發生關係。 一種不好的設計方案： 把一對多的關係暴露給外界，客戶程式即要處理一對一的關係，又要處理一對多的關係。

（根據MSDN Webcast相關課程整理）先看以下執行個體： 左邊的方案中客戶調用程式與子系統內部的具體實作類別具有較多的耦合與互動。顯然是不理想的設計方案。隨著外部客戶程式和各子系統的演化，這種過多的耦合將面臨居多變化的挑戰。 再看右邊的方案，外部客戶程式不再直接與子系統內部類直接互動，而是通過一個Façade介面實現內外系統之間的關聯，大大降低了系統的耦合性。 GoF：為子系統中的一組介面提供一個一致的介面，Facade模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

（根據MSDN Webcast相關課程整理）耦合關係直接決定軟體面對變化時的行為。 緊耦合時，當一個模組變化時，相關模組都要隨之更改；依賴關係複雜 松耦合時，模組更容易被替換或更改，而其他相關模組可以保持不變。依賴關係簡單（小圓點表示介面） 不要局限於某種設計模式採用的固定方法，只要能有效解決這種模式要解決的問題，那這種方法就屬於這種設計模式。

C#物件導向設計模式第一講：物件導向設計模式與原則 C#物件導向設計模式第二講：Singleton Pattern單件模式（建立型模式）C#物件導向設計模式第三講：Abstract Factory Pattern 抽象原廠模式（建立型模式）C#物件導向設計模式第四講：Builder Pattern產生器模式（建立型模式）C#物件導向設計模式第五講：Factory Method Factory 方法（建立型模式）C#物件導向設計模式第六講：Prototype

 本章是《從C#到Python》系列連載的最後一章，內容較簡單，主要介紹Python中模組與包的使用方法。如果你對這部分內容已經比較熟悉，就不要再浪費時間看了，寫這一章只是為了整個系列完整而已，沒什麼新的東西（本章內容主要參考了《Python精要參考》的第八章《模組和包》）。 5.1 

（根據MSDN WebCast相關課程整理）解決集合和訪問的問題。集合內部結構主要有鏈表式，順序式等。組件開發人員往往希望在不暴露組件內部結構的前提下，提供靈活的外部存取。GoF：提供一種方法順序的訪問一個彙總對象中的各個元素，而不暴露對象的各個組織圖。MyEnumerator繼承自IEnumerator，因此同樣相同的欄位和方法。在MyCollection中，通過GetEnumable()方法，獲得MyEnumerator對象，從而實現對MyCollection中對象的順序訪問。在C#環境中，

（根據MSDN WebCast相關課程整理）在一些情況下，請求的接收者可能多種多樣，變化無常，如所示： 請求的寄件者需要維護多個耦合，以處理請求資訊的傳達。這就存在多個強耦合。 GoF：使多個對象都有機會處理請求，從而避免請求的寄件者和接收者的耦合關係，將這些對象連成一條鏈，並沿著這條鏈傳遞請求，直到有一個對象處理了它為止。

一、將已經編譯後的java中Class檔案進行打包；打包命令JAR 如：將某目錄下的所有class檔案夾全部進行打包處理；使用的命令：jar cvf test.jar -C com/ .其中test.jar為要產生的jar包；com/ . 為指定的目前的目錄下的檔案夾，該檔案夾包括子檔案夾及class檔案；二、到IKVM官方網站下載IKVM需要的組件

0.0  寫在前面 前幾天寫了《從C#到Python ——

（根據MSDN WebCast相關課程整理）對象狀態變化無端，如何回溯或恢複這些對象在某個點的狀態呢？ GoF:在不破壞對象封裝性的前提下，捕獲一個對象的內部狀態，並在該對象外儲存這個狀態，這樣以後就可以將這個對象恢複到之前的狀態。 將對象的狀態儲存到了外部的Memento對象中，而在原發器對象內容提供儲存狀態和恢複狀態的操作。而備忘錄對象則只負責儲存對象的狀態，不支援原發器對象的所有操作。 也可以使用複製對象或序列化來儲存對象的狀態，我們可以根據實際情況和需要來選擇。 《完》

（根據MSDN WebCast相關課程整理）常用設計模式有23種，通常可以分為建立型（5種），結構型（7種）和行為型（11種）三大類型。 考察以下情境：ATM機操作中，當持人訂閱了簡訊，郵件等通知的話，當有人對卡面在ATM機上有操作時，就會即時發出簡訊或郵件。這就是所謂的觀察者模式。 當一個對象發生變化時，對它的變化感興趣的其它對象（訂閱了這個變化，即觀察者）都可以得到通知。 GoF：定義對象間的一種一對多的依賴關係，以便當一個對象的狀態發生變化時，所有依賴它的對象都能得到通知。

（根據MSDN WebCast相關課程整理）對象擁有不同的狀態，往往會行使不同的行為。 通常，我們可以採用switch…case語句來解決問題，但是，如果這種狀態變化比較頻繁，那麼，這必須導致對象與對象之間的緊耦合。當然，我們不要為使用設計模式而刻意的採用設計模式，因為一些簡 單案例下，採用模式可能反而會使設計更加複雜化。我們建議的項目初期不要刻意的應用模式，而是根據需要，找到變化點，漸進的重構出設計模式。 沒有採用設計模式時的情況:

（根據MSDN WebCast相關課程整理）這是一種應用非常廣泛的行為型設計模式。 對象可能經常需要用多種不同的演算法，但是如果變化頻繁，會將類型變得很脆弱。 如所示，對於一個立方休，取不同的截面，那麼它的面積計算方法就會不同，需要採用不同的演算法。 那麼，如何在運行時，不更改方法而動態設計演算法呢？將演算法與對象解耦，實現動態載入。 C#中動態可載入以支援運行時變化的技術手段有： 虛函數，介面，委託，反射

（根據MSDN WebCast相關課程整理）類階層中可能經常由於引入新的操作（虛方法），從而將類型變得脆弱。 如是一幅類繼承關係的階層圖， 如果在父類中直接增加一個虛方法時，所有的子類都可能需要改變。如何在不改變類層次與結構的前提下，在運行為根據需要透明的為各個類添加新的方法與操作。 GoF：表示一個作用於某種對象結構中的各元素的操作。它可以不改變各元素的類的前提下，定義作用於這些元素的新的操作。 沒有採用Visitor模式時：

在 C++中，庫的地位是非常高的。C++之父 Bjarne Stroustrup先生多次表示了設計庫來擴充功能要好過設計更多的文法的言論。現實中，C++的庫門類繁多，解決的問題也是極其廣泛，庫從輕量級到重量級的都有。不少都是讓人眼界大開，亦或是望而生歎的思維傑作。由於庫的數量非常龐大，而且限於筆者水平，其中很多並不瞭解。所以文中所提的一些庫都是比較著名的大型庫。 C++各大有名庫的介紹——科學計算 １、Blitz++參考網站：http://www.oonumerics.org/blitz 　 　

1、建立型模式： Singleton：解決的是執行個體化對象的個數的問題，比如抽象工廠中的工廠、對象池等，除了Singleton之外，其他建立型模式解決的都是 new 所帶來的耦合關係。 Abstract Factory：建立一系列相互依賴對象，並能在運行時改變系列。 Factory Method：建立單個對象，在Abstract Factory有使用到。 Prototype：通過拷貝原型來建立新的對象。 Factory Method，Abstract Factory,

終於靜下心來仔細聽了一遍Anders Hejlsberg（Visual Studio組的TECHNICAL FELLOW，C#的設計者之一）在PDC08上講的“The Future of