原创 2. 中介者模式

2.1. 模式動機 在用戶與用戶直接聊天的設計方案中,用戶對象之間存在很強的關聯性,將導致系統出現如下問題:系統結構複雜:對象之間存在大量的相互關聯和調用,若有一個對象發生變化,則需要跟蹤和該對象關聯的其他所有對象,並進行適當處理。對

原创 4. 狀態模式

4.1. 模式動機 在很多情況下,一個對象的行爲取決於一個或多個動態變化的屬性,這樣的屬性叫做狀態,這樣的對象叫做有狀態的(stateful)對象,這樣的對象狀態是從事先定義好的一系列值中取出的。當一個這樣的對象與外部事件產生互動時,

原创 3.抽象工廠模式(Abstract Factory)

3.1. 模式動機 在工廠方法模式中具體工廠負責生產具體的產品,每一個具體工廠對應一種具體產品,工廠方法也具有唯一性,一般情況下,一個具體工廠中只有一個工廠方法或者一組重載的工廠方法。但是有時候我們需要一個工廠可以提供多個產品對

原创 Git常用命令

一、概述 先用一幅圖,從總體上描述主要git命令的工作流程 workspace: 本地的工作目錄。(記作A)index:緩存區域,臨時保存本地改動。(記作B)local repository: 本地倉庫,只想最後一次提交HEAD。

原创 5. 單例模式

5.1. 模式動機 對於系統中的某些類來說,只有一個實例很重要,例如,一個系統中可以存在多個打印任務,但是只能有一個正在工作的任務;一個系統只能有一個窗口管理器或文件系統;一個系統只能有一個計時工具或ID(序號)生成器。 如何保證

原创 3. 觀察者模式

3.1. 模式動機 建立一種對象與對象之間的依賴關係,一個對象發生改變時將自動通知其他對象,其他對象將相應做出反應。在此,發生改變的對象稱爲觀察目標,而被通知的對象稱爲觀察者,一個觀察目標可以對應多個觀察者,而且這些觀察者之間沒有

原创 11. 命令模式

1.1. 模式動機 在軟件設計中,我們經常需要向某些對象發送請求,但是並不知道請求的接收者是誰,也不知道被請求的操作是哪個,我們只需在程序運行時指定具體的請求接收者即可,此時,可以使用命令模式來進行設計,使得請求發送者與請求接收者消除

原创 1.簡單工廠模式( Simple Factory Pattern )

1.1. 模式動機 考慮一個簡單的軟件應用場景,一個軟件系統可以提供多個外觀不同的按鈕(如圓形按鈕、矩形按鈕、菱形按鈕等), 這些按鈕都源自同一個基類,不過在繼承基類後不同的子類修改了部分屬性從而使得它們可以呈現不同的外觀,如果我們希

原创 2.工廠方法模式(Factory Method Pattern)

2.1. 模式動機 現在對該系統進行修改,不再設計一個按鈕工廠類來統一負責所有產品的創建,而是將具體按鈕的創建過程交給專門的工廠子類去完成,我們先定義一個抽象的按鈕工廠類,再定義具體的工廠類來生成圓形按鈕、矩形按鈕、菱形按鈕等,它們實

原创 7. 橋接模式

2.1. 模式動機 設想如果要繪製矩形、圓形、橢圓、正方形,我們至少需要4個形狀類,但是如果繪製的圖形需要具有不同的顏色,如紅色、綠色、藍色等,此時至少有如下兩種設計方案: 第一種設計方案是爲每一種形狀都提供一套各種顏色的版本。第

原创 10. 享元模式

5.1. 模式動機 面向對象技術可以很好地解決一些靈活性或可擴展性問題,但在很多情況下需要在系統中增加類和對象的個數。當對象數量太多時,將導致運行代價過高,帶來性能下降等問題。 享元模式正是爲解決這一類問題而誕生的。享元模式通過共

原创 4. 建造者模式

4.1. 模式動機 無論是在現實世界中還是在軟件系統中,都存在一些複雜的對象,它們擁有多個組成部分,如汽車,它包括車輪、方向盤、發送機等各種部件。而對於大多數用戶而言,無須知道這些部件的裝配細節,也幾乎不會使用單獨某個部件,而是使

原创 8. 裝飾模式

3.1. 模式動機 一般有兩種方式可以實現給一個類或對象增加行爲: 繼承機制,使用繼承機制是給現有類添加功能的一種有效途徑,通過繼承一個現有類可以使得子類在擁有自身方法的同時還擁有父類的方法。但是這種方法是靜態的,用戶不能控制增加行爲

原创 6. 適配器模式

1.1. 模式動機 在軟件開發中採用類似於電源適配器的設計和編碼技巧被稱爲適配器模式。通常情況下,客戶端可以通過目標類的接口訪問它所提供的服務。有時,現有的類可以滿足客戶類的功能需要,但是它所提供的接口不一定是客戶類所期望的,這可能是

原创 淺談HTTP RESTful架構

RESTful 是一種非常流行的軟件架構,或者說設計風格而非新的技術標準。提供了一組設計原則和約束條件,主要用於客戶端與服務器的交互。RESTful架構更簡潔,更有層次,更易於實現緩存等機制。 1.理解RESTful RESTfu