By SmartPtr(http://m.shnenglu.com/SmartPtr/)
Singleton應該可以算是GOF的23個模式中最簡單的一個模式了，它有兩個要求：一是保證一個類僅有一個實例；二是提供一個訪問它的全局訪問點。這在實現中分別對應為：一是構造函數非public；二是提供一個靜態函數作為全局訪問點。
在C#中，我們可以這么寫：
public class ExampleSingleton
{
// code to support Singleton
protected ExampleSingleton(){}
protected static ExampleSingleton instance = new ExampleSingleton();
public static ExampleSingleton Instance
{
get{return instance;}
}
// This class's real functionalities
public void Write(){Console.WriteLine("Hello, World!");}
}
// use this singleton class
ExampleSingleton.Instance.Write();
類似的，C++中實現如下：
class ExampleSingleton
{
// code to support Singleton
protected:
ExampleSingleton(){}
public:
static ExampleSingleton& Instance()
{
static ExampleSingleton instance;
return instance;
}
// This class's real functionalities
void Write(){printf("Hello, World!");}
};
// use this singleton class
ExampleSingleton::Instance().Write();
這樣寫的確符合了singleton的兩個要求，但是如果我們的系統中有許多個Singleton類，而對于每一個類，我們都要寫那些固定的，重復的代碼去支持其singleton的屬性。這不是一個好現象，我們希望可以把這些固定的代碼提取出來，使我們的Singleton類只需要專注于實現其真正的功能，相信很多人都聽說過這個做法：Singleton模板基類。
對于C#：
// Singleton base class, each class need to be a singleton should
// derived from this class
public class Singleton<T> where T: new()
{
// Instead of compile time check, we provide a run time check
// to make sure there is only one instance.
protected Singleton(){Debug.Assert(null == instance);}
protected static T instance = new T();
public static T Instance
{
get{return instance;}
}
}
// Concrete singleton class, derived from Singleton<T>
public class ExampleSingleton: Singleton<ExampleSingleton>
{
// since there is no "freind class" in C#, we have to make
// this contructor public to support the new constraint.
public ExampleSingleton(){}
// This class's real functionalities
public void Write(){Console.WriteLine("Hello, World!");}
}
// use this singleton class
ExampleSingleton.Instance.Write();
這里，我們把為了支持Singleton功能的代碼提到一個Singleton<T>的類模板當中，任何需要成為Singlton的類，只需從其派生便自然獲得Singleton功能。這里的一個問題是：為了支持模板類中的new()constraint，我們不得不把作為具體singleton類的派生類的構造函數作為public，這就導致我們無法在編譯期阻止用戶自行new出第二個，第三個實例來，但我們可以在運行期來進行檢查進而保證其實例的單一性，這就是這singleton基類構造函數的作用：
protected Singleton(){Debug.Assert(null == instance);}
當然，有另外一種實現方法，那就是singleton基類不提供new() constraint, 這樣我們就可以讓ExampleSingleton的構造函數為非public,在要創建T實例的時候，由于不能使用new, 我們用reflection反射出類型T的非public構造函數并調用之。這樣，我們的確能保證編譯期實例的唯一性，但是由于用了反射，感覺代碼不是那么的簡單優雅，并且對其性能持保留態度，所以不太傾向與這種方法。
但畢竟是越早檢查出錯誤越好，所以大家如果有好的解決方案，不妨提出來一起討論討論。
而C++中由于提供了友元這個特性，實現起來要好一些：
// Singleton base class, each class need to be a singleton should
// derived from this class
template <class T> class Singleton
{
protected:
Singleton(){}
public:
static T& Instance()
{
static T instance;
return instance;
}
};
// Concrete singleton class, derived from Singleton<T>
class ExampleSingleton: public Singleton<ExampleSingleton>
{
// so that Singleton<ExampleSingleton> can access the
// protected constructor
friend class Singleton<ExampleSingleton>;
protected:
ExampleSingleton(){}
public:
// This class's real functionalities
void Write(){printf("Hello, World!");}
};
// use this singleton class
ExampleSingleton::Instance().Write();
在C++友元的幫助下，我們成功實現了在編譯期保證實例的唯一性。（當然，前提是你不要"亂交朋友"）。
有人可能會問,實現singleton的代碼并不多，我們沒必要搞這么一個機制來做代碼復用吧？ 的確，我們復用的代碼并不是很多，但是，我想代碼復用的目的不僅僅是減少代碼量，其最重要的目的還是在于保持行為的一致性，以便于使用與維護。(用函數替換代碼段便是一個很好的例子)。
對于這里的singleton類來講，如果不做這個設計，我們在每個具體的singleton類內部實現其singleton機制，那么可能出現的問題是
1. 很難保證其接口的一致性
張三寫了一個singleton類，全局訪問函數是Instance, 李四也寫了一個Singleton類，全局訪問函數可能就是GetInstance了。。。。。我們并沒有一個健壯的機制來保證接口的一致性，從而導致了使用的混亂性。
2. 不易維護
Singleton創建實例有兩種：一種為lazy initialization, 一種就是early initialization, 假如開始的實現是所有的singleton都用lazy initialization， 突然某種需求要求你用early initialization，你的噩夢就開始了，你不得不重寫每一個singleton類。
而用了singleton模板基類這種機制，以上問題就不會存在，我們得到的不僅僅是節約幾行代碼:)
posted on 2007-07-17 23:54
SmartPtr 閱讀(1849)
評論(7) 編輯 收藏 引用