接口的目的是强制某个对象签名。它不应该明确地关心对象内部如何工作。因此，从概念的角度来看，接口中的构造函数并没有真正的意义。

不过也有一些替代方案:

Create an abstract class that acts as a minimal default implementation. That class should have the constructors you expect implementing classes to have. If you don't mind the overkill, use the AbstractFactory pattern and declare a method in the factory class interface that has the required signatures. Pass the GraphicsDeviceManager as a parameter to the Update and Draw methods. Use a Compositional Object Oriented Programming framework to pass the GraphicsDeviceManager into the part of the object that requires it. This is a pretty experimental solution in my opinion.

你描述的情况一般来说不容易处理。业务应用程序中需要访问数据库的实体也有类似的情况。

如前所述，在接口上不能有构造函数。但是，由于这是7年后谷歌中排名如此高的结果，我想我应该在这里补充一下——具体来说，是为了展示如何将抽象基类与现有的接口一起使用，并且可能会减少将来在类似情况下所需的重构量。在一些评论中已经暗示了这个概念，但我认为值得展示如何实际做到这一点。

到目前为止你的主界面是这样的:

public interface IDrawable
{
    void Update();
    void Draw();
}

现在用要强制的构造函数创建一个抽象类。实际上，自从你写你最初的问题以来，它就已经可用了，我们可以在这里稍微花点时间，在这种情况下使用泛型，这样我们就可以适应其他可能需要相同功能但有不同构造函数要求的接口:

public abstract class MustInitialize<T>
{
    public MustInitialize(T parameters)
    {

    }
}

现在你需要创建一个继承IDrawable接口和MustInitialize抽象类的新类:

public class Drawable : MustInitialize<GraphicsDeviceManager>, IDrawable
{
    GraphicsDeviceManager _graphicsDeviceManager;

    public Drawable(GraphicsDeviceManager graphicsDeviceManager)
        : base (graphicsDeviceManager)
    {
        _graphicsDeviceManager = graphicsDeviceManager;
    }

    public void Update()
    {
        //use _graphicsDeviceManager here to do whatever
    }

    public void Draw()
    {
        //use _graphicsDeviceManager here to do whatever
    }
}

然后只需创建一个Drawable实例，就可以了:

IDrawable drawableService = new Drawable(myGraphicsDeviceManager);

这里很酷的是，我们创建的新Drawable类仍然像我们期望的IDrawable一样。

如果需要向MustInitialize构造函数传递多个参数，可以创建一个类，为需要传递的所有字段定义属性。

虽然您不能在接口中定义构造函数签名，但我觉得值得一提的是，这可能是考虑抽象类的一个地方。抽象类可以以与接口相同的方式定义未实现的(抽象的)方法签名，但也可以有实现的(具体的)方法和构造函数。

缺点是，因为它是一种类类型，所以它不能用于接口可以使用的任何多继承类型场景。

你不。

构造函数是类的一部分，可以实现接口。接口只是类必须实现的方法的契约。

你不能。

接口定义了由其他对象实现的契约，因此不需要初始化状态。

如果需要初始化某些状态，则应该考虑使用抽象基类。

我发现解决这个问题的一个方法是将施工分离到一个单独的工厂。例如，我有一个名为IQueueItem的抽象类，我需要一种方法将该对象转换为另一个对象(CloudQueueMessage)。在IQueueItem接口上有-

public interface IQueueItem
{
    CloudQueueMessage ToMessage();
}

现在，我还需要一个方法为我的实际队列类转换一个CloudQueueMessage回IQueueItem -即需要一个静态结构，如IQueueItem objMessage = ItemType.FromMessage。相反，我定义了另一个接口IQueueFactory -

public interface IQueueItemFactory<T> where T : IQueueItem
{
    T FromMessage(CloudQueueMessage objMessage);
}

现在我终于可以在没有new()约束的情况下编写泛型队列类了，在我的例子中，new()约束是主要问题。

public class AzureQueue<T> where T : IQueueItem
{
    private IQueueItemFactory<T> _objFactory;
    public AzureQueue(IQueueItemFactory<T> objItemFactory)
    {
        _objFactory = objItemFactory;
    }


    public T GetNextItem(TimeSpan tsLease)
    {
        CloudQueueMessage objQueueMessage = _objQueue.GetMessage(tsLease);
        T objItem = _objFactory.FromMessage(objQueueMessage);
        return objItem;
    }
}

现在我可以创建一个满足条件的实例

 AzureQueue<Job> objJobQueue = new JobQueue(new JobItemFactory())

希望有一天这能帮助其他人解决问题，显然，为了显示问题和解决方案，删除了大量内部代码