自己编写类似于枚举的类型(多例模式)

场景

枚举,其实就是一种特殊的整数,只不过只能取一系列特定的值。通过 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
    }

}


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

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

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

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

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

好,继续向这个Document类中添加成员:

        foundation supports

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

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

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

还不够,我还想要枚举

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

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

        enum similar members

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

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

我变,变字符串,变回来

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

        type convert oeprators

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

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

再完美一点

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

        other functions

顺便附赠一个重写的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,我的确这样做了,发现写的时候是简单一些(只是一些而已),但用起来太麻烦了!所以才有了本文。

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

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

所以,在编写类型(及其成员)的时候,一切以“使用”为重。再多说一句,看看所谓设计模式,不都是希望“使用”起来容易一些么?
posted @ 2007-08-04 11:14  Anders Liu  阅读(2626)  评论(8编辑  收藏  举报