我应该使用哪种创作模式? [英] What creational pattern I should use?

查看:91
本文介绍了我应该使用哪种创作模式?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的程序有两个类;

class A : MyBase
{
    internal A(InitVal initVal)
}

class B : MyBase
{
    internal B(InitVal initVal)
}

InitVal 是另一个通过构造函数注入的类。此类仅供内部使用。由于内部构造函数,用户无法直接创建类 A B 的实例。相反,我创建了创建这些对象的方法。

InitVal is another class which is injected through constructor. This class is for internal usage. Due to internal constructor, user cannot create instance of class A and B directly. Instead, I created method which creates these objects.

class Initiator
{
    InitVal initVal;

    public T CreateObject<T>(ObjectInstance objectInstance) where T : MyBase
    {
        MyBase myBase = null;
        switch(objectInstance)
        {
            case ObjectInstance.A:
                myBase = new A(initVal);
                break;
            case ObjectInstance.B:
                myBase = new B(initVal);
                break;
        }
        return (T)myBase;
    }
    ...
}

ObjectInstance 是上面的代码中的枚举。

ObjectInstance is enum in above code.

这没有问题,但我相信您之前从未见过如此难看的代码。

This works without problem but I am sure you have never seen such ugly code earlier.

请提出我应该使用的创作模式。我想删除 ObjectInstance 枚举而不更改功能。

Please suggest creational pattern I should use. I want to remove ObjectInstance enum without changing functionality. It will cleanup much.

我尝试了 http://www.dofactory.com/net/上提到的创造性模式 design-patterns rel = nofollow>点工厂。
工厂方法抽象工厂在这种情况下看起来不合适。

I tried Creational Patterns mentioned on dotfactory. Factory Method and Abstract Factory does not look proper in this case.

我的代码虽然看上去很丑,但是却很容易阅读和理解。我尝试实现上述模式,这会增加代码的复杂性。因此,这也是选择答案时的标准。

My code even though look ugly, it is very simple to read and understand. I tried implementing patterns mentioned above which increases code complexity. So this is also my criteria while choosing answer.

除了 Initiator 类外,我无法更改代码中的任何内容。我无法访问所有其他班级进行编辑。

I cannot change anything in code except Initiator class. All other classes are not accessible to me for edit.

编辑1:为什么上述代码在我看来很丑

1)调用 CreateObject 方法时,用户必须两次指定对象的类型。

1) While calling CreateObject method, user have to specify type of the object twice.

A a = initiator.CreateObject<A>(ObjectInstance.A);

第一个表示 T 通用值,第二个表示枚举值。
我想避免这种情况。

First for T generic value and second to enum value. I want to avoid this.

2)由于用户必须两次指定对象类型,所以有出错的机会。

2) As user has to specify type of object twice, there are chances of mistake.

A a = initiator.CreateObject<A>(ObjectInstance.B);

在上面的代码中,枚举值和泛型值不同。
这是不允许的,将是一个问题。
我的代码无法避免。

In above code, enum value and generic value are different. This is not allowed and will be a problem. With my code, I cannot avoid this.

这就是为什么;我正在寻找适合我的情况的模式,而又不会增加复杂性。

That is why; I am looking for pattern that suits my case without increasing complexity.

如果我以某种方式消除了枚举的必要性,那么代码会更好。
如果可以将 CreateObject 的签名更改为以下内容,那就更好了。

If I remove necessity of enum somehow, code will be lot better. If I can change signature of CreateObject to following, it will be lot better.

public T CreateObject<T>() where T : MyBase

我不确定如何实现此方法来创建适当的实例。

But, I am not sure how I will implement this method to create proper instances.

推荐答案

在我看来,你看起来并不像通过尝试使这种通用性获得任何优势。您需要在调用站点上知道返回值的具体类型。

It doesn't look to me like you are getting any advantage from trying to make this generic. You needs to know the concrete type of the returned value at the call site.

因此,为什么不简化事情,而要这样做呢?

Therefore why not keep things simple and just do this?

public class Initiator
{
    InitVal initVal;

    public A CreateA()
    {
        return new A(initVal);
    }

    public B CreateB()
    {
        return new B(initVal);
    }
}

这篇关于我应该使用哪种创作模式?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆