跳到主要內容

獨體模式 (Singleton Pattern)

        單看名稱就很好理解的設計模式,就是只能有一個且是唯一實體的物件。有些時候最好讓物件只能有一個以避免程式出錯,例如負責處理使用者登入的物件,假如不是獨體模式的話,登入物件就可能有多個,使用者就可能同時登入很多次。

        設計此模式的想法也很簡單,不要讓別人能用 new 來建立物件就好,也就是建構子不能宣告為 public。因為其他人不能使用 private 建構子,只能在類別內使用…說那麼多,直接看程式碼比較快:

public class Singleton {

    // 利用一個靜態變數記綠 Singleton 的實體
    private static Singleton sInstance;

    // 可以宣告其他需要的成員變數

    // 建構式宣告為 private, 這樣只有在
    // Singleton 類別內才能使用
    private Singleton(){}

    // 公開的靜態方法, 其他人要取得物件只能使用此方法
    public static Singleton getInstance()
    {
        // 不為 null, 表示之前曾建立過, 不用再 new 一次
        if(sInstance == null)
        {
            // 需要時才建立物件, 稱為 lazy instantiaze
            sInstance = new Singleton();
        }

        return sInstance;
    }
}

        以上就是最基本的獨體模式,接下來來看一下正式定義及類別圖:

獨體模式確保一個類別只有一個實體,並給它一個存取的全域點(global point)
Ensure a class has only one instance and provide a global point of access to it.


        定義及實作上看起來雖然簡單,但在實務上可能會遇到問題。以上面的程式碼來看,是否真的只會有一個且唯一的物件呢 ? 以多執行緒的角度來看就可以知道,是有可能產生多個物件的,解決方法也不難,在 getInstance() 加上 synchronized 就可以了:
public static synchronized Singleton getInstance()
{
    if(sInstance == null)
    {
        sInstance = new Singleton();
    }

    return sInstance;
}
        這樣做看起來不錯,但是要考慮效能問題。因為只有第一次要 new 物件時才需要同步,這樣寫的話,每次要取得物件都要同步。因此可以改成以下方法:
public class Singleton {

    // 在靜態初始化方法(static initializer)中建立物件
    // 保證 thread safe
    private static Singleton sInstance = new Singleton();

    private Singleton(){}

    // 已經有實體了, 可以直接回傳
    public static Singleton getInstance()
    {
        return sInstance;
    }
}
        上面程式碼是例用 JVM 在載入此類別時,就馬上建立唯一的獨體物件。JVM 保證在任何執行緒存取 sInstance 之前會先建立物件。但假如在建立物件時需要比較大的 loading 時,此方法也不適用,因此還可以改為使用「雙重檢查上鎖」(double-checked locking) 的方式:
public class Singleton {

    // 利用 volatile, 可以保證此變數的值是一致的
    private volatile static Singleton sInstance;

    private Singleton(){}

    public static Singleton getInstance()
    {
        // 只有第一次建立物件才會完整執行此段程式
        if(sInstance == null)
        {
            synchronized (Singleton.class)
            {
                // 進入同步區後再檢查一次,
                // 還是 null 才建立實體
                if(sInstance == null)
                {
                    sInstance = new Singleton();
                }
            }
        }
        return sInstance;
    }
}
        雙重檢查上鎖只有要注意需要在 jdk 1.5 版以上才能用,1.4 以前的版本,對於 volatile 的實作會讓此方法失效

參考資料:

        深入淺出設計模式(Head First Design Patterns)

留言

這個網誌中的熱門文章

訪問者模式 (Visitor Pattern)

        假設你設計一個系統,其中會有一些相似類別,類別中都有某些方法內容相似,但還是需要判斷目前要做事的是哪個類別才能呼叫對應的適當類別。通常遇到這種情情,在 Java 中最直接的做法就是使用 instanceof 關鍵字來判斷,如以下的簡單範例: public interface CarComponent { public void printMessage(); } public class Wheel implements CarComponent { @Override public void printMessage() { System.out.println("This is a wheel"); } // 這是 Wheel 跟 Engine 不同的方法 public void doWheel() { System.out.println("Checking wheel..."); } } public class Engine implements CarComponent { @Override public void printMessage() { System.out.println("This is a engine"); } // 這是 Wheel 跟 Engine 不同的方法 public void doEngine() { System.out.println("Testing this engine..."); } } public class Car { private List mComponents; public Car() { mComponents = new ArrayList<carcomponent>(); } // 有些時候我們還是需要針對不同類別去做不同的事情 public void setComponent(CarCompon...

責任鏈模式 (Chain of Responsibility Pattern)

        假設你的公司時常會收到不同的電子郵件如垃圾信,顧客的抱怨信,顧客的感謝信等等,而公司希望對這些不同類型的信都先用制式的罐頭信回應 (就是 不同的信件有不同的處理方式 )。當你要寫程式處理公司的電子郵件時,直接寫在一個 class 是最簡單的作法。但你勢必會用到 if/else 或 switch 等來判斷不同的信件,而這樣做有一些缺點,例如 程式複雜性增加,不夠彈性,擴充困難 等等。當你希望 多個物件 (處理信的方式) 都有機會能處理相同請求時 (新寄來的電子郵件) 時,可以考慮責任鏈模式。先介紹此模式的正式定義及類別圖: 讓多個物件都有機會可以處理請求,以避免請求的發送者和接受者之間產生耦合關係。將這些物件連成一條鏈,並沿著這條鏈傳遞請求,直到有一個物件處理這個請求為止。 Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.         從類別圖來看這個模式很單純,每個子類別都有要實作的方法來處理它們能處理的特殊請求。 當有不能處理的請求時,也能傳給下一個子類別繼續處理 。當然這邊就是由設計者自行決定要有幾個子類別來處理哪些不同的請求,以及決定這些子類別傳遞請求的順序為何。         接著來看一下套用責任鏈模式的簡單程式碼吧 // 所有處理郵件的子類別要繼承的介面 public abstract class MailHandler { // 每個處理郵件類別都要記錄下一個 // 能處理的人是誰 protected MailHandler mHandler; public MailHandler(MailHandler handler) { mHandler = handl...

狀態模式 (State Pattern)

        如果今天你要設計一台如下圖的糖果機,你會怎麼設計呢?         有上過資訊相關課程的人,應該不難從上圖聯想到 狀態圖 ,上圖中每個圓圈都是一個狀態,而每個箭頭就代表狀態的轉換。有了這個概念後,把它轉成程式就不難了: public class CandyMachine { // 以下四個值表示糖果機會用到的狀態 final static int SOLD_OUT = 0; final static int NO_COIN = 1; final static int HAS_COIN = 2; final static int SOLD = 3; // 需要有一個變數來記錄目前的狀態 // 初始設為賣完, 因為一開始機器裡沒糖果 int mState = SOLD_OUT; // 也要有另一個變數記錄目前剩多少顆糖果 int mCount = 0; public CandyMachine(int count) { mCount = count; // 機器內有糖果的話就跳到沒投錢的狀態, // 表示糖果機在等人投錢 if(mCount > 0) { mState = NO_COIN; } } // 當投錢時會執行這個方法 public void insertCoin() { if(mState == HAS_COIN) { System.out.println("You can't insert another coin"); } else if(mState == NO_COIN) { mState == HAS_COIN; System.out.println("You inserted a coin"); } ...