自己编写类似于枚举的类型（多例模式）

场景

枚举，其实就是一种特殊的整数，只不过只能取一系列特定的值。通过 enum Type : short 这样的语法，我们可以指定枚举在底层究竟使用哪种整数。

然而，有的时候我们希望自定义类型，其实例有着各种我们所需要的成员；但同时我们又希望这个类型只有有限个实例，用户只能从其中取一个使用。

比如，Anders Liu有一个系统，能够处理Word、Html和Text格式的文档，现在我希望定义一个DocumentType类型，表示所有支持的文档类型；但对于每一种类型，Anders Liu又偏偏希望它具有诸如Processor（处理这种类型文档的程序）和Extension（这种类型的文档的扩展名）等属性。

此时就出现了矛盾。如果使用枚举，必然无法实现这些实例属性。但是，如果自己编写一个类呢？

在这篇文章中，Anders Liu将带你一起实现一个用起来像枚举，但实际上是自定义类型的类。

我要的对象，它不是整数

首先，毕竟我们所需要的是对象，而不是枚举所提供的简单整数。所以，先定义好再说：

namespace  AndersLiu.Samples.EnumSimilarClass
{
    /**//// <summary>
    /// Indicates the surpported document types.
    /// You cannot inherits from this class.
    /// </summary>
    /// <remarks>
    /// This class looks very like an enum.
    /// </remarks>
    public sealed class DocumentType
    {
        instanse members#region instanse members
        string _name;
        string _processor;
        string _extension;

        /**//// <summary>
        /// Initialize a <see cref="DocumentType"/> instance.
        /// This constructor is private, so that user cannot construct it from external.
        /// </summary>
        /// <param name="name">Name of the document type.</param>
        /// <param name="processor">Processor of the document.</param>
        /// <param name="extension">Extension of the document.</param>
        private DocumentType(string name, string processor, string extension)
        {
            _name = name;
            _processor = processor;
            _extension = extension;
        }

        /**//// <summary>
        /// Name of the document type.
        /// </summary>
        public string Name
        {
            get
            {
                return _name;
            }
        }

        /**//// <summary>
        /// Processor of the document.
        /// </summary>
        public string Processor
        {
            get
            {
                return _processor;
            }
        }

        /**//// <summary>
        /// Extension of the document.
        /// </summary>
        public string Extension
        {
            get
            {
                return _extension;
            }
        }
        #endregion
    }
}

在这里，要注意的是，这个DocumentType类型的构造器被定义成了private，因为毕竟我们所提供的只是有限个对象，所以不希望客户代码创建它的实例。

这个类型非常简单，如果构造器是public的，我想它就已经完成了。

有限个实例，我给你准备好

既然我们只能支持已知的几种类型，不如先准备好，放在一个静态的集合中。

用哪种集合类型最好呢？Anders Liu偏爱Dictionary。因为Dictionary在检索成员时的时间复杂度是O(1)！

好，继续向这个Document类中添加成员：

         foundation supports #region foundation supports
        static Dictionary<string, DocumentType> _allTypes;

        // Indicates the documents' type name.
        const string WordTypeName = "Word";
        const string HtmlTypeName = "Html";
        const string TextTypeName = "Text";

        // Indicates which application can be used to open the document.
        const string WordProcessor = "winword.exe";
        const string HtmlProcessor = "iexplorer.exe";
        const string TextProcessor = "notepad.exe";

        // Indicates the file extension of each document type.
        const string WordExtension = ".doc";
        const string HtmlExtension = ".html";
        const string TextExtension = ".txt";

        /**//// <summary>
        /// Static constructor. Initializes all supported document types.
        /// </summary>
        static DocumentType()
        {
            _allTypes = new Dictionary<string, DocumentType>();

            _allTypes.Add(WordTypeName, new DocumentType(WordTypeName, WordProcessor, WordExtension));
            _allTypes.Add(HtmlTypeName, new DocumentType(HtmlTypeName, HtmlProcessor, HtmlExtension));
            _allTypes.Add(TextTypeName, new DocumentType(TextTypeName, TextProcessor, TextExtension));
        }
        #endregion

现在，所有支持的文档类型实例就都位于这个_allTypes中了。

为了让程序漂亮一些，所有用到的字符串都使用常量代替了。我想聪明的你应该会喜欢。

其实，如果我们将XxxTypeName常量设置为public的，再通过一个只读属性公开_allTypes集合，我想，我们又已经写好了一个类，而且完全可以投入使用了。

还不够，我还想要枚举

人的贪念是无限的。Anders Liu也是如此，Anders Liu吹毛求疵、追求那并不存在的完美。

为了使用起来更像枚举，我们再添加一系列静态属性：

         enum similar members #region enum similar members
        /**//// <summary>
        /// Word document.
        /// </summary>
        public static DocumentType Word
        {
            get { return _allTypes[WordTypeName]; }
        }

        /**//// <summary>
        /// Html document.
        /// </summary>
        public static DocumentType Html
        {
            get { return _allTypes[HtmlTypeName]; }
        }

        /**//// <summary>
        /// Text document.
        /// </summary>
        public static DocumentType Text
        {
            get { return _allTypes[TextTypeName]; }
        }
        #endregion

这样就明朗了吧？我想聪明的读者已经可以看出这个类型的使用场景了。

枚举还有一个特征，那就是可以与其底层的整数进行相互转换，还可以通过枚举成员的名字来得到枚举对象——这一切都不是非常负责。那么我们这个“仿枚举”，也应该如此。

我变，变字符串，变回来

这个简单，用自定义类型转换运算符就可以完成：

         type convert oeprators #region type convert oeprators
        /**//// <summary>
        /// Implicit convert <see cref="DocumentType"/> object to <see cref="string"/>.
        /// </summary>
        /// <param name="type">A given document type.</param>
        /// <returns>The type name.</returns>
        public static implicit operator string(DocumentType type)
        {
            return type.Name;
        }

        /**//// <summary>
        /// Explicit convert <see cref="string"/> object to <see cref="DocumentType"/>.
        /// </summary>
        /// <param name="typeName">Given document type name.</param>
        /// <returns>The corresponsive document type.</returns>
        public static explicit operator DocumentType(string typeName)
        {
            if(_allTypes.ContainsKey(typeName))
                return _allTypes[typeName];
            else
                throw new InvalidOperationException(string.Format("'{0}' is not a valid document type.", typeName));
        }
        #endregion

这些就不用多解释了，如果你不会编写自定义类型转换运算符，那可该补补C#了。 :)

——看啊，抛异常了，显式转换的时候抛异常了！
——这有什么大惊小怪？很多时候做类型转换都会抛异常的。
——可是，抛异常影响效率……
——这……你这个人怎么比Anders Liu还追求“完美”啊？！

再完美一点

加一个判断，用来检测一个字符串是不是有效的文档类型名字，省得转换时抛异常：

         other functions #region other functions
        /**//// <summary>
        /// Indicates a given type name is valid or not.
        /// </summary>
        /// <param name="typeName">Given type name.</param>
        /// <returns>Whether the <see cref="typeName"/> is vliad.</returns>
        public static bool IsValidDocumetTypeName(string typeName)
        {
            return _allTypes.ContainsKey(typeName);
        }

        /**//// <summary>
        /// Override. Generate the string representation of the current object.
        /// </summary>
        /// <returns>The string representation.</returns>
        public override string ToString()
        {
            return string.Format(
                "{0} (Processor=[{1}], Extension=[{2}])",
                _name,
                _processor,
                _extension);
        }
        #endregion

顺便附赠一个重写的ToString方法。重写ToStrig方法也是一个好习惯，毕竟我们不希望当客户代码将这个类型的对象写到控制台上的时候，都千篇一律地是类型的名字。

好了，写到这里，这个DocumentType类就圆满了。

是骡子是马，拉出来溜溜

建一个WinForm项目，写一个方法：

         /**/ /// <summary>
        /// Process a document with given type.
        /// </summary>
        /// <param name="doc">Type of the document.</param>
         private   void  process(DocumentType doc)
         {
            string msg = string.Format(
                "I'm working with a {0} document in {1}.",
                (string)doc, doc.Processor);  // Look, use it just like a normal object.

            MessageBox.Show(msg);
        }

加一个按钮，试一试：

         private   void  btnProcessWord_Click( object  sender, EventArgs e)
         {
            process(DocumentType.Word);  // Look, it looks similarly an enum!
        }

         private   void  btnProcessHtml_Click( object  sender, EventArgs e)
         {
            process(DocumentType.Html);
        }

         private   void  btnProcessText_Click( object  sender, EventArgs e)
         {
            process(DocumentType.Text);
        }

哦，不好意思，因为太简单了，所以加多了，这是三个。

看看，是不是很像枚举？但我们并没有丧失对象的实例属性。

啊哈，新的设计模式

——这个标题明显夸张了，其实大家可能经常在按这种习惯写代码，只不过没察觉罢了。
——可是，所谓“设计模式”，不就是那些我们经常用到的“习惯”么？

现在，我们简化一下上面的例子。假设只支持一种文档类型——Text。去掉额外的代码（读者自己去掉把，我辛辛苦苦写的可不想删），你发现了什么？

好，如果你还没看出来，再把类型的名字改成TextDocumentType，然后把仅剩的静态属性改成“Instance”这样的名字。

OK，是不是“单例”模式出来了？

所以，我们这里写的类型，不过就是比单例模式多几个“例”而已。前文其实也一直在暗示——多个实例、有限个实例……

因此，这种模式就是——多例模式，你叫“N例模式”、“有限例模式”也可以啦。

Show Me The Code

如果没记错，这应该是3D游戏大师Carmark（卡马克）的名言吧【参见《DOOM启示录》】。

想看代码？这里有： http://www.codeplex.com/a/Release/ProjectReleases.aspx?ReleaseId=6242。

你可以不信，但别反驳我

有人会有反对意见的——搞这么复杂干嘛？定义一个枚举，再定义一个类型，提供按照枚举取实例的方法多好。

Anders Liu要说的是，本文绝对来源于实践而非YY，我的确这样做了，发现写的时候是简单一些（只是一些而已），但用起来太麻烦了！所以才有了本文。

要记住，对于一个类型，永远存在着这样的公理：

使用一个类型的几率比定义这个类型的几率大很多。同理适用于类型的成员。

所以，在编写类型（及其成员）的时候，一切以“使用”为重。再多说一句，看看所谓设计模式，不都是希望“使用”起来容易一些么？