Interfaz definiendo una firma de constructor?

No puedes. Ocasionalmente es un dolor, pero no podrías llamarlo usando técnicas normales de todos modos.

En una entrada de blog he sugerido interfaces estáticas que solo serían utilizables en restricciones de tipo genérico, pero podrían ser realmente útiles, IMO.

Un punto acerca de si pudiera definir un constructor dentro de una interfaz, tendría problemas para derivar clases:

public class Foo : IParameterlessConstructor
{
    public Foo() // As per the interface
    {
    }
}

public class Bar : Foo
{
    // Yikes! We now don't have a parameterless constructor...
    public Bar(int x)
    {
    }
}

Una contribución muy tardía que demuestra otro problema con los constructores interconectados. (Elijo esta pregunta porque tiene la articulación más clara del problema). Supongamos que podríamos tener:

interface IPerson
{
    IPerson(string name);
}

interface ICustomer
{
    ICustomer(DateTime registrationDate);
}

class Person : IPerson, ICustomer
{
    Person(string name) { }
    Person(DateTime registrationDate) { }
}

Donde por convención la implementación del "constructor de interfaz" se sustituye por el nombre del tipo.

Ahora crea una instancia:

ICustomer a = new Person("Ernie");

¿Diríamos que el contrato ICustomer es obedecido?

Y qué hay de esto:

interface ICustomer
{
    ICustomer(string address);
}

No puedes.

Las interfaces definen contratos que otros objetos implementan y, por lo tanto, no tienen ningún estado que necesite inicializarse.

Si tiene algún estado que necesita inicializarse, debería considerar usar una clase base abstracta en su lugar.

No es posible crear una interfaz que defina constructores, pero es posible definir una interfaz que obliga a un tipo a tener un constructor sin parámetros, aunque sea una sintaxis muy fea que usa genéricos... En realidad no estoy tan seguro de que sea realmente un buen patrón de codificación.

public interface IFoo<T> where T : new()
{
  void SomeMethod();
}

public class Foo : IFoo<Foo>
{
  // This will not compile
  public Foo(int x)
  {

  }

  #region ITest<Test> Members

  public void SomeMethod()
  {
    throw new NotImplementedException();
  }

  #endregion
}

Por otro lado, si quieres probar si un tipo tiene un constructor sin parámetros, puedes hacerlo usando reflexión:

public static class TypeHelper
{
  public static bool HasParameterlessConstructor(Object o)
  {
    return HasParameterlessConstructor(o.GetType());
  }

  public static bool HasParameterlessConstructor(Type t)
  {
    // Usage: HasParameterlessConstructor(typeof(SomeType))
    return t.GetConstructor(new Type[0]) != null;
  }
}

Espero que esto ayude.

Estaba mirando hacia atrás en esta pregunta y pensé para mí mismo, tal vez estamos abordando este problema de la manera equivocada. Las interfaces pueden no ser el camino a seguir cuando se trata de definir un constructor con ciertos parámetros... pero una clase base (abstracta) lo es.

Si crea una clase base con un constructor allí que acepta los parámetros que necesita, cada clase que derrive de ella necesita suministrarlos.

public abstract class Foo
{
  protected Foo(SomeParameter x)
  {
    this.X = x;
  }

  public SomeParameter X { get; private set }
}

public class Bar : Foo // Bar inherits from Foo
{
  public Bar() 
    : base(new SomeParameter("etc...")) // Bar will need to supply the constructor param
  {
  }
}

El enfoque genérico de fábrica todavía parece ideal. Usted sabría que la fábrica requiere un parámetro, y simplemente sucedería que esos parámetros se pasan a lo largo del constructor del objeto que se instancian.

Nota, esto es solo pseudo código verificado por sintaxis, puede haber una advertencia en tiempo de ejecución que me falta aquí:

public interface IDrawableFactory
{
    TDrawable GetDrawingObject<TDrawable>(GraphicsDeviceManager graphicsDeviceManager) 
              where TDrawable: class, IDrawable, new();
}

public class DrawableFactory : IDrawableFactory
{
    public TDrawable GetDrawingObject<TDrawable>(GraphicsDeviceManager graphicsDeviceManager) 
                     where TDrawable : class, IDrawable, new()
    {
        return (TDrawable) Activator
                .CreateInstance(typeof(TDrawable), 
                                graphicsDeviceManager);
    }

}

public class Draw : IDrawable
{
 //stub
}

public class Update : IDrawable {
    private readonly GraphicsDeviceManager _graphicsDeviceManager;

    public Update() { throw new NotImplementedException(); }

    public Update(GraphicsDeviceManager graphicsDeviceManager)
    {
        _graphicsDeviceManager = graphicsDeviceManager;
    }
}

public interface IDrawable
{
    //stub
}
public class GraphicsDeviceManager
{
    //stub
}

Un ejemplo de posible uso:

    public void DoSomething()
    {
        var myUpdateObject = GetDrawingObject<Update>(new GraphicsDeviceManager());
        var myDrawObject = GetDrawingObject<Draw>(null);
    }

Concedido, solo desea que las instancias de create a través de la fábrica para garantizar que siempre tiene un objeto inicializado apropiadamente. Quizás usar un framework de inyección de dependencias como AutoFac tendría sentido; Update() podría "pedir" al contenedor IoC un nuevo objeto GraphicsDeviceManager.

Una forma de resolver este problema que encontré es separar la construcción en una fábrica separada. Por ejemplo, tengo una clase abstracta llamada IQueueItem, y necesito una forma de traducir ese objeto hacia y desde otro objeto (CloudQueueMessage). Así que en la interfaz IQueueItem tengo -

public interface IQueueItem
{
    CloudQueueMessage ToMessage();
}

Ahora, también necesito una forma para que mi clase de cola real traduzca un CloudQueueMessage a un IQueueItem-es decir, la necesidad de una construcción estática como IQueueItem objMessage = ItemType.Desde el mensaje. En su lugar, definí otra interfaz IQueueFactory -

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

Ahora finalmente puedo escribir mi clase de cola genérica sin la restricción new() que en mi caso fue el problema principal.

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;
    }
}

Ahora puedo crear una instancia que satisfaga los criterios para mí

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

Esperemos que esto ayude a alguien más algún día, obviamente una gran cantidad de código interno eliminado para tratar de mostrar el problema y la solución

Una forma de resolver este problema es aprovechar los genéricos y la restricción new ().

En lugar de expresar su constructor como un método/función, puede expresarlo como una clase/interfaz de fábrica. Si especifica la restricción genérica new () en cada sitio de llamadas que necesita crear un objeto de su clase, podrá pasar argumentos de constructor en consecuencia.

Para su ejemplo IDrawable:

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

public interface IDrawableConstructor<T> where T : IDrawable
{
    T Construct(GraphicsDeviceManager manager);
}


public class Triangle : IDrawable
{
    public GraphicsDeviceManager Manager { get; set; }
    public void Draw() { ... }
    public void Update() { ... }
    public Triangle(GraphicsDeviceManager manager)
    {
        Manager = manager;
    }
}


public TriangleConstructor : IDrawableConstructor<Triangle>
{
    public Triangle Construct(GraphicsDeviceManager manager)
    {
        return new Triangle(manager);
    } 
}

Ahora cuando lo usas:

public void SomeMethod<TBuilder>(GraphicsDeviceManager manager)
  where TBuilder: IDrawableConstructor<Triangle>, new()
{
    // If we need to create a triangle
    Triangle triangle = new TBuilder().Construct(manager);

    // Do whatever with triangle
}

Incluso puedes concentrarte todos los métodos de creación en una sola clase usando implementación de interfaz explícita:

public DrawableConstructor : IDrawableConstructor<Triangle>,
                             IDrawableConstructor<Square>,
                             IDrawableConstructor<Circle>
{
    Triangle IDrawableConstructor<Triangle>.Construct(GraphicsDeviceManager manager)
    {
        return new Triangle(manager);
    } 

    Square IDrawableConstructor<Square>.Construct(GraphicsDeviceManager manager)
    {
        return new Square(manager);
    } 

    Circle IDrawableConstructor<Circle>.Construct(GraphicsDeviceManager manager)
    {
        return new Circle(manager);
    } 
}

Para usarlo:

public void SomeMethod<TBuilder, TShape>(GraphicsDeviceManager manager)
  where TBuilder: IDrawableConstructor<TShape>, new()
{
    // If we need to create an arbitrary shape
    TShape shape = new TBuilder().Construct(manager);

    // Do whatever with the shape
}

Otra forma es usando expresiones lambda como inicializadores. En algún momento temprano en la jerarquía de llamadas, sabrá qué objetos necesitará instanciar (es decir, cuando esté creando o obteniendo una referencia a su objeto GraphicsDeviceManager). Tan pronto como lo tenga, pase la lambda

() => new Triangle(manager) 

A métodos posteriores para que sepan cómo crear un Triángulo a partir de entonces. Si no puede determinar todos los métodos posibles que necesitará, siempre puede crear un diccionario de tipos que implementen IDrawable usando reflexión y registrar la expresión lambda mostrada anteriormente en un diccionario que puede almacenar en una ubicación compartida o pasar a otras llamadas a funciones.

Usted podría hacer esto con truco genérico, pero todavía es vulnerable a lo que Jon Skeet escribió:

public interface IHasDefaultConstructor<T> where T : IHasDefaultConstructor<T>, new()
{
}

La clase que implementa esta interfaz debe tener un constructor sin parámetros:

public class A : IHasDefaultConstructor<A> //Notice A as generic parameter
{
    public A(int a) { } //compile time error
}

No lo haces.

El constructor es parte de la clase que puede implementar una interfaz. La interfaz es solo un contrato de métodos que la clase debe implementar.

Sería muy útil si fuera posible definir constructores de interfaces.

Dado que una interfaz es un contrato que debe utilizarse de la manera especificada. El siguiente enfoque podría ser una alternativa viable para algunos escenarios:

public interface IFoo {

    /// <summary>
    /// Initialize foo.
    /// </summary>
    /// <remarks>
    /// Classes that implement this interface must invoke this method from
    /// each of their constructors.
    /// </remarks>
    /// <exception cref="InvalidOperationException">
    /// Thrown when instance has already been initialized.
    /// </exception>
    void Initialize(int a);

}

public class ConcreteFoo : IFoo {

    private bool _init = false;

    public int b;

    // Obviously in this case a default value could be used for the
    // constructor argument; using overloads for purpose of example

    public ConcreteFoo() {
        Initialize(42);
    }

    public ConcreteFoo(int a) {
        Initialize(a);
    }

    public void Initialize(int a) {
        if (_init)
            throw new InvalidOperationException();
        _init = true;

        b = a;
    }

}

Una forma de forzar algún tipo de constructor es declarar solo Getters en interface, lo que podría significar que la clase implementadora debe tener un método, idealmente un constructor, para tener el valor establecido (privately) para él.

Si bien no se puede definir una firma de constructor en una interfaz, creo que vale la pena mencionar que este puede ser un lugar para considerar una clase abstracta. Las clases abstractas pueden definir firmas de métodos no implementadas (abstractas) de la misma manera que una interfaz, pero también pueden tener implementados métodos y constructores (concretos).

La desventaja es que, debido a que es un tipo de clase, no se puede usar para ninguno de los escenarios de tipo de herencia múltiple que una interfaz puede.

El propósito de una interfaz es imponer una firma de objeto determinada. Explícitamente no debe preocuparse por cómo funciona un objeto internamente. Por lo tanto, un constructor en una interfaz realmente no tiene sentido desde un punto de vista conceptual.

Sin embargo, hay algunas alternativas:

• Cree una clase abstracta que actúe como una implementación predeterminada mínima. Esa clase debe tener los constructores que espera implementar clases a tener.

• Si no le importa el exceso, utilice el patrón AbstractFactory y declarar un método en la interfaz de clase de fábrica que tiene el firma.

• Pase el GraphicsDeviceManager como parámetro a los métodos Update y Draw.

• Utilice un marco de Programación Orientado a Objetos de Composición para pasar el GraphicsDeviceManager a la parte del objeto que lo requiere. Esta es una solución bastante experimental en mi opinión.

La situación que describir no es fácil de manejar en general. Un caso similar serían las entidades en una aplicación comercial que requieren acceso a la base de datos.

Si entendí OP correctamente, queremos hacer cumplir un contrato donde GraphicsDeviceManager siempre se inicializa mediante la implementación de clases. Tenía un problema similar y estaba buscando una solución mejor, pero esto es lo mejor que se me ocurre:

Agregue un SetGraphicsDeviceManager(GraphicsDeviceManager gdo) a la interfaz, y de esa manera las clases implementadoras se verán obligadas a escribir una lógica que requerirá una llamada del constructor.