其他

【1】基本概念          面板模式(Facade)，為子系統中的一組介面提供一個一致的介面，此模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。【2】簡單分析          我們先來看下該設計模式的UML結構圖：【3】如何用java語言實現該設計模式：由於該設計模式比較簡單，而且我們平時在開發項目的過程中經常會用到該設計模式的，我就不做過多的解析了，針對上面的UML結構圖分別貼出各個類的代碼：3.1 SubSystemOne.java源碼：package

【1】基本概念          狀態模式(State)，當一個對象的內在狀態改變時允許改變其行為，這個對象看起來像是改變了其類。【2】簡單分析       

 1、概念定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一主題對象，這個主題的狀態發生變化是就通知所有的觀察者對象，是這些觀察者自動更新自己。2、角色觀察者(Observer)—觀察者有一個更新自己狀態的方法，當它觀察的那個主題的裝太發生了變化，主題會通知這些觀察者，觀察者接到通知後更新自己的狀態。所以觀察者有一個Update()方法。主題(Subject)—主題包含多個觀察者，就有ADD和REMOVE觀察者的方法。該主題的狀態改變了需要通知那些觀察者，所以還有一個Notify()方法。

 1、概念    當一個對象的內在狀態改變時允許改變其行為，這個對象看起來像是改變了其類。主要解決，當一個對象狀態轉換的條件運算式過於複雜時把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中。將複雜的邏輯判斷簡化。2、模型    有三個角色，    State——抽象狀態類，封裝一個與特定狀態相關的行為。    CreateState——具體狀態，實現一個特定狀態的行為。    ConText——維護一個CreateState執行個體，該執行個體是根據狀態傳入的。 程式實現： public

【1】基本概念           建造(Builder)模式是一種對象構建的設計模式，它可以將複雜物件的建造過程抽象出來（抽象類別），使這個抽象過程的不同實現方法可以構造出不同表現（屬性）的對象。【2】簡單分析我們先來看一下該設計模式的UML結構圖是Strategy

 1、  概念    定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類不改變演算法的結構也可以重定義某些演算法的特定步驟。2、  模型    模板方法模式在編程中是經常用到的，就不做詳細解釋了。常見模型如下：using System;using System.Collections.Generic;using System.Text;namespace TemplateMethod{ public abstract class

 1、  概念將一個類的介面轉換成另外一個 使用者希望的介面，解決由於介面不相容而不能一起工作類，能一起工作。2、  模型Target——用戶端希望的介面。NeedAdapter——新增的類，沒有實現Target介面。由於用戶端只認Target的一系列方法，所以NeedAdapter沒法在用戶端使用。Adapter——適配器，實現Target介面，並負責當調用Target時，能調用NeedAdapter的方法。模型圖： //原始的介面 public abstract class

【1】基本概念         

單一職責原則 就一個類而言，應該僅有一個引起它變化的原因。職責即為“變化的原因”。 開放封閉原則 軟體實體（類、模組、函數等）應該是可以擴充的，但是不可修改。對於擴充是開放的,對於更改是封閉的。關鍵是抽象，將一個功能的通用部分和實現細節部分清晰的分離開來。理氏替換原則 子類型必須能替換掉他們的基本類型。依賴倒置原則

1、  概念為子系統中的一組介面提供一個一致的介面，此模式定義了一個高層介面，該介面使子系統更加容易使用。2、  模型 public class ModularA { public void ModularAMethod() { Console.WriteLine("A模組的方法。"); } } public class ModularB { public void

【1】基本概念          觀察者模式定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一主題對象。這個主題對象在狀態發生變化時，會通知所有觀察者對象，使它們能夠自動更新自己。觀察者模式又叫發布-訂閱(Publish/Subscribe)模式。【2】簡單分析 我們先來看一下該設計模式的UML結構圖是Observer

 1、概念將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。2、角色產品（Product）——根據不同建造者建造的結果；抽象建造者（Builder）——包含詳細的建造步驟；指揮者（Director）——安排如何建造，如何安排步驟的先後順序；具體的建造者——根據不同的需求，實現Builder的步驟，每一步驟如何?是不同的，但是Builder中的所有步驟必須都要有。 3、模型各角色的實現using System;using

我們知道，函數調用是靠棧來實現的，編譯器協助我們做了壓棧和恢複堆棧工作，使我們在調用任一個函數時，都不用進行壓棧和恢複堆棧工作。而又由於實現的方式很多，那我們怎麼告訴編譯器按照哪種方式呢？答案是函數呼叫慣例(function call convention).函數呼叫慣例(function call convention)是什嗎？    函數呼叫慣例本質上是告訴編譯器怎麼把進階語言編譯成彙編代碼。這裡編譯器要解決幾個問題：    1

公開金鑰加密演算法，非對稱金鑰。RSA公開金鑰加密演算法是1977年由Ron Rivest、Adi

【1】基本概念          裝飾模式(Decorator)，動態地給一個對象添加一些額外的職責，就增加功能來說，裝飾模式比產生子類更為靈活。【2】簡單分析          我們先來看下該設計模式的UML結構圖是Decorator

本機作業系統為xp，virtualbox版本為4.1，虛擬機器為CentOS 6。安裝vitualbox增強功能的步驟：1.啟動CentOS2.在virtualbox菜單中選擇“裝置-->安裝增強功能”，會在案頭上出現一個“VBOXADDITIONS_4.1”表徵圖3.進入終端模式執行# ln -s /usr/src/kernels/2.6...  /usr/src/linux   //省略符號處用TAB鍵補全#cd /media/VB...# sh VBoxLinuxAdditions-

 1、  概念在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外儲存這個狀態。這樣以後就可將該對象恢複至儲存時的狀態。2、  模型角色：Originator(發起者)——建立備忘錄Memorandum，並且根據需要決定，需要儲存那些狀態。Memorandum(備忘錄)——負責儲存Originator對象的內部狀態，並防止Originator以外的對象訪問這個備忘錄。Caretaker(管理者)——負責儲存備忘錄。程式模型：//發起者，需要儲存狀態的對象 public class

 1、定義：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支援可撤消的操作。[GOF 《設計模式》]2、角色Command——用來執行操作的介面。CreateCommand——將一個接收者對象綁定一個動作，並實現執行命令操作。Invoker——要求該命令執行。Receiver——知道如何實施與執行一個與請求相關的操作，任何類都可作為一個接收者。3、模型Command abstract class Command {

概念    將對象組合成樹形結構以表示‘部分-整體’的階層。組合模式使得使用者對單個對象和組合對象的使用具有一致性。角色    Component：組合中對象介面    Leaf：葉子，繼承自Component    Composite：分支，繼承自Component   

 概念 將抽象部分和與之對應的實現部分分離，使它們可以獨立地變化。角色Implementor—— 定義實作類別的介面CreateImplementorFirst（CreateImplementorSecond）——實現Implementor介面及定義其具體實現。Abstraction——定義抽象的介面。是依據Implementor所構成的高階操作。RefinedAbstraction—— 擴充Abstraction。程式實現模型先看看，程式的實現：Implementor public