Métodos estáticos y de instancia con el mismo nombre?

Question

Tengo una clase con una interfaz estática y una no estática en C#. ¿Es posible tener un método estático y no estático en una clase con el mismo nombre y firma?

Aparece un error de compilación cuando trato de hacer esto, pero por alguna razón pensé que había una manera de hacerlo. ¿Estoy equivocado o no hay forma de tener métodos estáticos y no estáticos en la misma clase?

Si esto no es posible, ¿hay una buena manera de implementar algo como esto que se pueda aplicar genéricamente a cualquier situación?

EDITAR
partir de las respuestas que he recibido, está claro que no hay manera de hacer esto. Voy con un sistema de nombres diferente para evitar este problema.

Answer 1

No, no puedes. El motivo de la limitación es que los métodos estáticos también se pueden invocar desde contextos no estáticos sin necesidad de anteponer el nombre de la clase (así que MyStaticMethod() en lugar de MyClass.MyStaticMethod()). El compilador no puede decir qué estás buscando si tienes ambos.

Puede tener métodos estáticos y no estáticos con el mismo nombre, pero diferentes parámetros que siguen las mismas reglas que la sobrecarga de métodos, simplemente no pueden tener exactamente la misma firma.

Answer 2

Usted puede llamar a métodos estáticos de los métodos de instancia sin tener que especificar el nombre del tipo:

class Foo 
{ 
    static void Bar() 
    { 
    } 

    void Fizz() 
    { 
     Bar(); 
    } 
} 

... así que tiene sentido que no se le permitiría tener un método estático y un método de instancia con la misma firma

¿Qué estás tratando de lograr? Es difícil sugerir una solución alternativa sin conocer los detalles. Solo cambiaría el nombre a uno de los métodos.

Answer 3

Puede tener métodos estáticos y de instancia con el mismo nombre, siempre que su declaración difiera en el número o tipo de parámetros. Es la misma regla sobre cómo puede tener dos métodos de instancia con el mismo nombre en una clase.

Aunque técnicamente, en el caso de método estático frente a instancia, ya difieren por la presencia del parámetro implícito en el método de instancia, esa diferencia no es suficiente para que el compilador determine cuál de los dos desea llamada.

Actualización: He cometido un error. Los valores de devolución no son suficientes para tener una firma diferente.

Answer 4

En realidad, hay una manera de lograr esto mediante la implementación explícita de una interfaz. No es una solución perfecta, pero puede funcionar en algunos casos.

interface IFoo 
{ 
    void Bar(); 
} 

class Foo : IFoo 
{ 
    static void Bar() 
    { 
    } 

    void IFoo.Bar() 
    { 
     Bar(); 
    } 
} 

a veces me encuentro con esta situación cuando hago clases de envoltura para P/Invoke llamadas.

Answer 5

OK. El origen de este problema es que C# no debería permitirle llamar a un método estático desde un método de instancia sin especificar el nombre del tipo.

Otros lenguajes completos de OO (como Smalltalk) no permiten esto y también es una confusión para las personas que entienden los objetos. La separación entre el lado de la instancia y el lado de la clase (o estática) es muy importante y tener un lenguaje que promueva confusión en esos detalles es ........ no una buena idea ... pero típico del tipo de cosas que esperar de MS.

Adrian

Answer 6

C# no está bien diseñado, cuando se trata de esto ...

Si bien es cierto que lo que pueda desear lo global o no global, debe escoger uno por defecto, y si quieres el otro, entonces simplemente lo calificas más.

class Logger { 
    public static Logger instance; 

    public static void Log(string message) { 
     instance.Log(message); // currently the compiler thinks this is ambiguous, but really its not at all. Clearly we want the non-static method 
    } 

    public void Log(string message) { 

    } 

    public void DoStuff() { 
     Log("doing instance stuff"); // this could be ambiguous, but in my opinion it should default to a call to this.Log() 
     Logger.Log("doing global stuff"); // if you want the global qualify it explicitly 
    } 
}