| | | | | | | [文章信息] | | | 作者: | Mark Townsend | | 时间: | 2004-08-02 | | 出处: | MSDN开发精选6月刊 | | 责任编辑: | 方舟 | |
| [文章导读] | | | 在本文中，我们将讨论Singleton模式，它包含在创造性模式系列中 | |
| |
|
| | | |
|
|
|
|
|
另一种试图解决此问题的方法可能是，在成员变量声明中使用volatile关键字。这应该告诉编译器不要对代码重新排序，并且放弃优化。目前，这是唯一建议的JVM内存模型，并且不会立即解决该问题。
实现Singleton的最好方法是什么？最终（而不是碰巧），Microsoft .NET框架解决了所有这些问题，从而更易于实现Singleton，却不会产生我们目前讨论的不利副作用。.NET框架以及C#语言允许我们在必要时通过替换语言关键字，将上述的Java语法移植到C#语法。因此，Singleton代码变为以下内容：
以C#编码的双重检验锁定
// Port to C#
class Singleton
{
public staticSingletonInstance() {
if (_instance == null) {
lock (typeof(Singleton)) {
if (_instance == null) {
_instance = new Singleton();
}
}
}
return _instance;
}
protected Singleton() {}
private static volatileSingleton_instance = null;
} |
此处，我们替换了锁定关键字来执行关键部分块，使用typeof操作并添加volatile关键字，以确保没有对代码进行优化程序重新排序。虽然此代码或多或少是GoFSingleton模式的直接移植，但它可达到我们的目的，并且我们可获得所需的行为。此代码还说明了将C++移植到Java和将Java移植到C#代码的一些相似之处和主要差别。但是，正如任何代码移植一样，通常目标语言或平台的一些优点可能在移植过程中失去。需要做的就是对代码重构，以便利用新目标语言或平台的功能。
在前面的每个代码示例中，Singleton的原始实现随时间的推移而发生变化，以解决在每个新模式实现中发现的问题。一些问题（例如，线程安全）要求对大多数实现进行更改，以满足在目前应用程序中日益增长的需要并解决演变发展问题。.NET在应用程序开发中提供了一个演变步骤。可以在“框架”级别解决前面示例中出现的很多亟待解决的问题，而不是在实现级别解决。虽然上一个示例显示了一个使用.NET框架和C#的有效Singleton类，但只需更好地利用.NET框架本身就可以大大简化此代码。以下示例使用.NET，它是一个松散地基于原始GoF模式的最小限度的Singleton类，并且仍然可获得类似的行为。
.NETSingleton示例
//.NET Singleton
sealed class Singleton
{
private Singleton() {}
public static readonlySingletonInstance = new Singleton();
} |
此版本已大大简化并且更加直观。它仍然是Singleton吗？让我们看一下更改了哪些内容，然后再做决定。我们修改了要密封的类本身（该类密封后是不可继承的），删除了惰性初始化代码，删除了Instance()方法，并且对_instance变量做了大量的修改。对_instance变量所做的更改包括修改对公共方法的访问级别，将变量标记为只读，以及在声明时初始化该变量。此处，我们可以直接定义所需的行为，而不关心实现的潜在有害的副作用。那么，使用惰性初始化有什么优点以及使用多个线程有什么危险呢？在.NET框架中内置了所有正确的行为。让我们先看第一种情况：惰性初始化。
最初使用惰性初始化的主要原因是要获取仅在第一次调用Instance()方法中创建实例的行为，还因为C++规范中具有某种开放性，并不定义静态变量的确切初始化顺序。要在C++中获得所需的Singleton行为，必须采用涉及使用惰性初始化的运算方法。我们真正关心的是在第一次（在该情况下）调用实例属性中创建该实例，还是在此调用之前创建该实例的，并且类中的静态变量是否有已定义的初始化顺序。对于.NET框架，这就是我们获取的行为。在JIT过程中，当（且仅当）任何方法使用静态属性时，“框架”将初始化此静态属性。如果没有使用该属性，则不会创建实例。更准确地说，在JIT过程中发生的事情就是，在任何调用方使用该类的任何静态成员时构造和加载该类。在这种情况下，结果是相同的。
那么，线程安全初始化呢？“框架”也解决了这一问题。“框架”内部保证静态类型初始化的线程安全。换句话说，在上面的示例中，只创建一个Singleton类实例。还要注意，用于保存类实例的属性字段称为实例。此选项更好地说明了，在本文中的讨论过程中，此值是类的实例。在“框架”本身中，虽然使用的属性名称称为值，但有多个类使用此类型的Singleton。概念完全相同。
对类所做的其他更改意味着禁止划分子类。添加密封类修饰符可确保不会将该类划分为子类。GoFSingleton模式详细介绍了试图对Singleton划分子类所产生的问题，该划分通常并不是小事。在大多数情况下，可以很容易地开发没有父类的Singleton，并且添加划分子类功能会增加通常根本不需要的新的复杂性级别。随着复杂性的提高，测试、培训和文档编制等所需的时间也会增加。通常，除非绝对必要，否则您不希望提高任何代码的复杂性。
让我们看一下如何使用Singleton。使用我们最初的计数器的有关动机的概念，我们可以创建一个简单的Singleton计数器类并说明我们将如何使用它。图3显示了UML类说明将包含什么内容。
相应的类实现代码以及示例客户端使用如下所示。
示例Singleton使用
sealed class SingletonCounter {
public static readonly SingletonCounter Instance =
new SingletonCounter();
private long Count = 0;
private SingletonCounter() {}
public long NextValue() {
return ++Count;
}
}
class SingletonClient {
[STAThread]
static void Main() {
for (int i=0; i<20; i++) {
Console.WriteLine("NextSingletonvalue: {0}",
SingletonCounter.Instance.NextValue());
}
}
} |
此处，我们还创建了一个Singleton类来维护具有long类型的增量计数。客户端是一个简单的控制台应用程序，它显示计数器类的20个值。虽然此示例极其简单，但它却说明了如何使用.NET来实现Singleton，然后将其用在应用程序中。
小结
Singleton设计模式是一个非常有用的机制，可用于在面向对象的应用程序中提供单个对象访问点。无论使用的是什么实现，该模式提供一个大家所熟知的概念，以便其在设计和开发小组之间方便地进行共享。但是，正如我们所发现的一样，注意到这些实现有多大差异及其潜在的副作用也是非常重要的。.NET框架为模式实现者在设计所需的功能类型方面提供了很大的帮助，实现者无需处理本文中所讨论的很多副作用。在正确实现后，可以证实模式的最初目的的有效性。
设计模式是非常有用的软件设计概念，可使小组将重点放在提供最佳类型的应用程序上，而不考虑它们是什么应用程序。关键在于正确而有效地使用设计模式，目前有很多关于将设计模式用于Microsoft .NET方面的MSDN系列文档，其中介绍了如何正确而有效地使用设计模式。
|
|
|
|
|
|
|
|
|
