Warum lässt nicht C # Statische Methoden eine Schnittstelle implementieren?

StackOverflow https://stackoverflow.com/questions/259026

  •  06-07-2019
  •  | 
  •  

Frage

Warum wurde C # auf diese Weise entworfen?

Wie ich es verstehe, eine Schnittstelle nur Verhalten beschreibt, und dient dem Zweck, eine vertragliche Verpflichtung für die Klassen der Beschreibung der Umsetzung der Schnittstelle, dass ein bestimmtes Verhalten implementiert wird.

Wenn Klassen wünschen, dass behavour in einem gemeinsamen Verfahren zu implementieren, warum soll sie nicht?

Hier ist ein Beispiel dafür, was ich im Sinn haben: 

// These items will be displayed in a list on the screen.
public interface IListItem {
  string ScreenName();
  ...
}

public class Animal: IListItem {
    // All animals will be called "Animal".
    public static string ScreenName() {
        return "Animal";
    }
....
}

public class Person: IListItem {

    private string name;

    // All persons will be called by their individual names.
    public string ScreenName() {
        return name;
    }

    ....

 }
War es hilfreich?

Lösung

Angenommen, Sie fragen, warum Sie dies nicht tun: 

public interface IFoo {
    void Bar();
}

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

Das macht keinen Sinn für mich machen, semantisch. Methoden für eine Schnittstelle spezifiziert sollte es sein, den Vertrag zu geben, um mit einem Objekt interagieren. Statische Methoden erlauben Sie nicht mit einem Objekt zu interagieren - wenn Sie sich in der Position, wo Ihre Implementierung statisch gemacht werden könnte, kann man sich fragen müssen, ob das Verfahren in der Schnittstelle wirklich gehört.

Zur Umsetzung Ihres Beispiels, ich würde Tiere eine konst Eigenschaft, die immer noch erlauben würde es von einem statischen Kontext zugegriffen werden, und zurück, dass Wert bei der Umsetzung. 

public class Animal: IListItem {
    /* Can be tough to come up with a different, yet meaningful name!
     * A different casing convention, like Java has, would help here.
     */
    public const string AnimalScreenName = "Animal";
    public string ScreenName(){ return AnimalScreenName; }
}

Für eine komplizierte Situation, man konnte immer eine andere statische Methode und Delegierten festzustellen. Bei dem Versuch, mit einem Beispiel kam, konnte ich denke nicht an irgendeinem Grund etwas nicht-trivial sowohl in einem statischen und Instanzkontext tun würde, also wird ich Dir einen FooBar blob schonen, und es als Hinweis nehmen, dass es vielleicht nicht eine gute Idee sein.

Andere Tipps

My (vereinfachte) technischer Grund ist, dass statische Methoden sind nicht in dem VTable und die Aufrufort wird bei der Kompilierung gewählt. Es ist der gleiche Grund, warum Sie nicht überschreiben oder virtuelle statische Mitglieder haben. Für weitere Informationen, würden Sie einen CS grad oder Compiler wonk müssen - von denen ich weder bin

.

Für den politischen Grund, ich werde Zitat Eric Lippert (der ein Compiler wonk ist, und einen Bachelor of Mathematics, Informatik und Angewandte Mathematik an der University of Waterloo (Quelle gilt: < a href = "https://www.linkedin.com/pub/eric-lippert/85/934/a38" rel = "noreferrer"> LinkedIn ):

  

... der Kern Konstruktionsprinzip der statischen Methoden, das Prinzip, das ihnen ihren Namen gibt ... [ist] ... es kann immer genau bestimmt werden, bei der Kompilierung, welche Methode aufgerufen wird. Das heißt, kann das Verfahren nur durch statische Analyse des Codes aufgelöst werden.

Beachten Sie, dass Lippert tut lassen Raum für eine so genannte Typ-Methode:

  

Das heißt, ein Verfahren mit einer Art zugeordnet ist (wie ein statisch), die kein nicht-nullable „dieses“ Argument nimmt (im Gegensatz zu einer Instanz oder virtuell), aber ein, wo das Verfahren würde hängen von dem konstruierten Typ genannt von T (im Gegensatz zu einem statischen, das bei der Kompilierung bestimmbar sein muss).

ist aber noch von seiner Nützlichkeit überzeugt werden.

Die meisten Antworten hier scheinen den ganzen Punkt zu verpassen. Polymorphismus kann nicht nur zwischen den Fällen verwendet werden, sondern auch zwischen verschiedenen Arten. Dies wird oft benötigt, wenn wir Generika verwenden.

Angenommen, wir Typ-Parameter in der generischen Methode haben, und wir müssen mit ihr eine Operation zu tun. Den wir nicht instantinate wollen, weil wir nichts von den Konstrukteuren sind.

Zum Beispiel: 

Repository GetRepository<T>()
{
  //need to call T.IsQueryable, but can't!!!
  //need to call T.RowCount
  //need to call T.DoSomeStaticMath(int param)
}

...
var r = GetRepository<Customer>()

Leider kann ich nur mit „hässlich“ Alternativen kommen:

  • Verwenden Reflexion Hässliche und schlägt die Idee von Schnittstellen und Polymorphismus.

  • Erstellen völlig getrennte Factory-Klasse

    Dies könnte die Komplexität des Codes erheblich erhöhen. Zum Beispiel, wenn wir Domain-Objekte zu modellieren versuchen müßte jedes Objekt eine andere Repository-Klasse.

  • instanziieren und dann auf die gewünschte Schnittstelle Methode aufrufen

    Das kann hart sein, selbst zu implementieren, wenn wir die Quelle für die Klassen, als generische Parameter steuern. Der Grund dafür ist, dass zum Beispiel könnten wir die Instanzen müssen nur in bekannten, Zustand „DB verbunden“ sein.

Beispiel: 

public class Customer 
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  void SomeOtherMethod() 
  { 
    //do work...
  }
}

, um instantination zu verwenden, für die Lösung der statischen Schnittstelle Problem, das wir brauchen, das Folgende tun: 

public class Customer: IDoSomeStaticMath
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  //dummy instance
  public Customer() { IsDummy = true; }

  int DoSomeStaticMath(int a) { }

  void SomeOtherMethod() 
  { 
    if(!IsDummy) 
    {
      //do work...
    }
  }
}

Das ist natürlich hässlich und auch unnötig kompliziert den Code für alle anderen Methoden. Offensichtlich keine elegante Lösung entweder!

Ich weiß, es ist eine alte Frage, aber es ist interessant. Das Beispiel ist nicht die beste. Ich denke, es wäre viel klarer, wenn Sie einen Anwendungsfall zeigen: 

string DoSomething<T>() where T:ISomeFunction
{
  if (T.someFunction())
    ...
}

Lediglich der Lage, statische Methoden haben implementieren eine Schnittstelle würde nicht erreichen, was Sie wollen; was notwendig wäre wäre statische Mitglieder zu haben, wie Teil eine Schnittstelle. Ich kann sicherlich viele Anwendungsfälle für das vorstellen, vor allem, wenn es darum geht, die Dinge in der Lage zu schaffen. Zwei Ansätze, die ich anbieten könnte, die hilfreich sein könnten:

  1. Erstellen Sie eine statische generische Klasse, deren Typ-Parameter wird der Typ sein, das Sie vorbei sein würde oben auf doSomething. Jede Variation dieser Klasse eine oder mehrere statische Mitglieder Sachen dieser Art im Zusammenhang halten. Diese Informationen könnten geliefert entweder durch jede Klasse von Interesse Anruf mit einer „Registerinformationen“ Routine oder durch Reflexion unter Verwendung der Informationen zu erhalten, wenn die Klasse Variation der statischen Konstruktor ausgeführt wird. Ich glaube, dieser Ansatz durch Dinge wie Comparer verwendet wird .Default ().
  2. T Für jede Klasse von Interesse, definiert eine Klasse oder Struktur, die IGetWhateverClassInfo implementiert und erfüllt eine „neue“ constraint. Die Klasse enthält eigentlich keine Felder, sondern eine statische Eigenschaft haben, die ein statisches Feld mit der Typinformation zurückgibt. Übergeben Sie den Typ dieser Klasse oder Struktur auf die generische Routine in Frage, die eine Instanz zu schaffen in der Lage, und es verwenden, Informationen über die andere Klasse zu erhalten. Wenn Sie eine Klasse für diesen Zweck verwenden, sollten Sie wahrscheinlich eine statische generische Klasse definieren, wie oben angegeben, um zu vermeiden, eine neue Descriptor-Objekt-Instanz jedes Mal zu konstruieren. Wenn Sie eine Struktur verwenden, sollten Instanziierung Kosten gleich Null sein, aber jede andere Strukturtyp würde eine andere Erweiterung der DoSomething Routine erfordern.

Keiner dieser Ansätze ist wirklich ansprechend. Auf der anderen Seite, würde ich erwarten, dass, wenn die Mechanismen in CLR existieren diese Art von Funktionalität sauber zu schaffen, .net einer erlauben würde parametrisierte „neuen“ Constraints (da zu wissen, zu bestimmen, ob eine Klasse einen Konstruktor mit einer bestimmten Signatur scheint zu wissen, vergleichbar in Schwierigkeiten zu sein, wenn es eine statische Methode mit einer bestimmten Signatur).

Schnittstellen Verhalten eines Objekts angeben.

Statische Methoden nicht angeben, ein Verhalten eines Objekts, sondern Verhalten, das wirkt sich ein Objekt in irgendeiner Weise.

In dem Maße, repräsentieren „Verträge“ Schnittstellen, so scheint es ruhig vernünftig für statische Klassen-Schnittstellen zu implementieren.

Die obigen Argumente scheinen alle diesen Punkt über Verträge zu verpassen.

Kurzsichtigkeit, ich würde vermuten.

Wenn ursprünglich entworfen wurden Schnittstellen soll nur mit Instanzen der Klasse verwendet werden 

IMyInterface val = GetObjectImplementingIMyInterface();
val.SomeThingDefinedinInterface();

Erst mit der Einführung von Schnittstellen als Einschränkungen für Generika haben eine praktische Anwendung eine statische Methode zu einer Schnittstelle hinzugefügt haben.

(Antwort auf einen Kommentar :) Ich glaube es ändert sich jetzt für eine Änderung des CLR erfordern würde, was zu Inkompatibilitäten mit bestehenden Baugruppen führen würde.

Da der Zweck einer Schnittstelle ist Polymorphismus zu ermöglichen, eine Instanz einer beliebigen Anzahl von definierten Klassen weitergeben zu können, die alle bisher definiert haben die definierte Schnittstelle zu implementieren ... garantiert, dass innerhalb Ihres polymorphen Anrufs, wird der Code sein die Lage, die Methode, die Sie anrufen zu finden. es macht keinen Sinn, eine statische Methode zu ermöglichen, die Schnittstelle zu implementieren,

Wie würden Sie es nennen ?? 

public interface MyInterface { void MyMethod(); }
public class MyClass: MyInterface
{
    public static void MyMethod() { //Do Something; }
}

 // inside of some other class ...  
 // How would you call the method on the interface ???
    MyClass.MyMethod();  // this calls the method normally 
                         // not through the interface...

    // This next fails you can't cast a classname to a different type... 
    // Only instances can be Cast to a different type...
    MyInterface myItf = MyClass as MyInterface;

In Bezug auf statische Methoden in nicht-generischen Kontext stimme ich zu, dass es nicht viel Sinn macht, sie in Schnittstellen zu ermöglichen, da man sie nicht zu nennen wäre in der Lage, wenn Sie ohnehin einen Verweis auf die Schnittstelle hatte. Allerdings gibt es eine grundlegende Loch in der Sprache Design unter Verwendung von Schnittstellen nicht in einem polymorphen Kontext geschaffen, sondern nur in einem allgemeinen ein. In diesem Fall ist die Schnittstelle keine Schnittstelle überhaupt, sondern ein Zwang. Da C # kein Konzept einer Einschränkung außerhalb einer Schnittstelle hat es fehlt wesentliche Funktionalität. Typischer Fall: 

T SumElements<T>(T initVal, T[] values)
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

Hier gibt es keinen Polymorphismus, der generische den tatsächlichen Typ des Objekts verwendet und ruft den Operator + =, aber dies nicht gelingt, da es nicht sicher sagen kann, dass dieser Operator vorhanden ist. Die einfache Lösung ist es in der Nebenbedingung zu spezifizieren; die einfache Lösung ist nicht möglich, da Betreiber statische und statische Methoden nicht in einer Schnittstelle sein können und (hier ist das Problem) Einschränkungen werden als Schnittstellen dargestellt.

Welche C # braucht, ist ein echter Einschränkungsart würden alle Schnittstellen auch Einschränkungen, aber nicht alle Zwänge Schnittstellen wäre dann können Sie dies tun: 

constraint CHasPlusEquals
{
    static CHasPlusEquals operator + (CHasPlusEquals a, CHasPlusEquals b);
}

T SumElements<T>(T initVal, T[] values) where T : CHasPlusEquals
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

Es hat eine Menge Gerede bereits über eine IArithmetic für alle numerischen Typen machen zu implementieren, aber es gibt Bedenken hinsichtlich Effizienz, da eine Einschränkung nicht ein polymorphes Konstrukt ist, eine CArithmetic Einschränkung machte das Problem lösen würde.

Da Schnittstellen in Vererbungsstruktur ist und statische Methoden erben nicht gut.

Was Sie scheinen für eine statische Methode erlauben würde, wollen sowohl die Art oder jede Instanz dieses Typs über aufgerufen werden. Dies würde bei dest Ergebnis in Mehrdeutigkeit, die kein wünschenswertes Merkmal ist.

Es würde über endlose Debatten, ob es wichtig, die beste Praxis ist und ob es Performance-Probleme ihm eine oder andere Weise zu tun. Durch einfaches unterstützt es nicht C # spart uns darüber Gedanken machen zu müssen.

Es ist auch wahrscheinlich, dass ein Kompilier, die diesen Wunsch entsprochen würde einige Optimierungen verlieren, die mit einer strikten Trennung zwischen Instanz und statischen Methoden kommen können.

Sie können denken Sie an die statischen Methoden und nicht-statische Methoden einer Klasse als verschiedene Schnittstellen zu sein. Wenn sie aufgerufen wird, lösen statische Methoden zum Singleton statischen Klassenobjekt und nicht-statische Methoden lösen mit der Instanz der Klasse, die Sie beschäftigen. Also, wenn Sie statische und nicht-statische Methoden in einer Schnittstelle verwenden, dann würden Sie effektiv zwei Schnittstellen sein zu erklären, wenn wir wirklich wollen Schnittstellen verwendet werden, um Zugriff auf eine zusammenhängende Sache.

Um ein Beispiel zu geben, wo ich entweder statische Implementierung von Interface-Methoden am fehlt oder was Mark Brackett als eingeführt „so genannten Typ-Methode“:

Wenn Sie von einem Datenbank-Speichern lesen, haben wir eine generische Datatable-Klasse, die aus einer Tabelle jeder Struktur Griffe zu lesen. Alle Tabelle spezifische Informationen in einer Klasse pro Tisch gelegt, die auch Daten für eine Zeile aus der DB hält und die eine IDataRow Schnittstelle implementieren muß. Inbegriffen im IDataRow ist eine Beschreibung der Struktur der Tabelle aus der Datenbank zu lesen. Die Datentabelle muss für die Datenstruktur von der IDataRow fragen, bevor aus der DB zu lesen. Derzeit wird diese wie folgt aussieht: 

interface IDataRow {
  string GetDataSTructre();  // How to read data from the DB
  void Read(IDBDataRow);     // How to populate this datarow from DB data
}

public class DataTable<T> : List<T> where T : IDataRow {

  public string GetDataStructure()
    // Desired: Static or Type method:
    // return (T.GetDataStructure());
    // Required: Instantiate a new class:
    return (new T().GetDataStructure());
  }

}

Die GetDataStructure wird nur einmal benötigt für jede Tabelle der Aufwand zu lesen, zum Instanziieren eine weitere Instanz ist minimal. Allerdings wäre es hier in diesem Fall schön.

Zur Info: Sie könnten ein ähnliches Verhalten bekommen, was Sie wollen durch Erweiterungsmethoden für die Schnittstelle zu schaffen. Die Erweiterung Methode würde ein gemeinsames, nicht außer Kraft gesetzt werden statisches Verhalten sein. Doch leider diese statische Methode wäre nicht Bestandteil des Vertrages sein.

Schnittstellen sind abstrakte Sätze von definierten verfügbaren Funktionen.

Unabhängig davon, ob ein Verfahren in dieser Schnittstelle als statisch verhält oder nicht, ist ein Implementierungsdetail, das hinter der Schnittstelle ausgeblendet werden soll . Es wäre falsch, eine Interface-Methode als statisch zu definieren, weil Sie unnötig die Methode zwingen würden in einer bestimmten Art und Weise umgesetzt werden.

Wenn -methoden als statisch definiert wurde, die Klasse die Schnittstelle implementiert, würde nicht so verkapselt, wie es sein könnte. Die Verkapselung ist eine gute Sache zu streben in objektorientiertes Design (Ich werde nicht gehen in warum Sie das hier lesen: http://en.wikipedia.org/wiki/Object-oriented ). Aus diesem Grunde sind statische Methoden in Schnittstellen nicht zulässig.

Statische Klassen sollten in der Lage sein, dies zu tun, so dass sie allgemein verwendet werden. Ich musste stattdessen eine Singleton implementieren, um die gewünschten Ergebnisse zu erzielen.

hatte ich ein paar Static Business Layer-Klassen, die CRUD Methoden wie „Create“ implementiert, „Lesen“, „Update“, „Löschen“ für jeden Entitätstyp wie „Benutzer“, „Team“, ect .. ich dann erstellt eine Steuerbasis, die eine abstrakte Eigenschaft für die Business-Schicht-Klasse hatte, die die CRUD Methoden implementiert. Die erlaubte mir, den „Create“, „Lesen“, „Update“, „Delete“ -Operationen von der Basisklasse zu automatisieren. Ich hatte einen Singleton zu verwenden, da der statischen Begrenzung.

Die meisten Menschen scheinen zu vergessen, dass in OOP-Klassen sind auch Objekte, und so haben sie Nachrichten, die aus irgendeinem Grund c # „statische Methode“ nennt. Die Tatsache, dass Unterschiede zwischen Instanzobjekten und Klassenobjekten zeigt nur Fehler oder Mängel in der Sprache. Optimist über c # aber ...

OK hier ist ein Beispiel, um eine ‚Typ-Methode‘. Ich schaffe eine von einer Reihe von Klassen auf einer Quelle XML basiert. Also ich habe ein 

  static public bool IsHandled(XElement xml)

Funktion, die wiederum auf jeder Klasse aufgerufen wird.

Die Funktion sollte statisch sein, da wir sonst Zeit zu schaffen unangemessene Objekte verschwenden. Wie @Ian Boyde weist darauf hin, es in einer Fabrik Klasse getan werden könnte, aber das kommt noch hinzu, Komplexität.

Es wäre schön, um es in die Schnittstelle hinzuzufügen Klasse Implementierer zu zwingen, sie umzusetzen. Dies würde nicht erheblichen Mehraufwand führen. - es ist nur eine Überprüfung der Kompilierung / link Zeit und wirkt sich nicht auf die V-Tabelle

Es wäre jedoch auch eine ziemlich geringfügige Verbesserung. Da das Verfahren statisch ist, ich als Anrufer, muss sie explizit aufrufe und so einen sofortigen Compiler-Fehler, wenn es nicht umgesetzt wird. So dass sie an der Schnittstelle festgelegt werden würde diesen Fehler bedeuten kommt geringfügig früher im Entwicklungszyklus, aber das ist trivial im Vergleich zu anderen aufgebrochene Schnittstellenproblemen.

So ist es eine kleine Potential-Funktion, die auf Balance ist wahrscheinlich am besten außen vor.

Die Tatsache, dass eine statische Klasse in C # implementiert wird von Microsoft eine spezielle Instanz einer Klasse mit den statischen Elementen schaffen, ist nur eine Kuriosität, wie statische Funktionalität erreicht wird. Es ist kein theoretischer Punkt.

Eine Schnittstelle soll ein Beschreiber der Klasse Schnittstelle sein - oder wie es mit interagierten und das soll Interaktionen umfassen, die statisch sind. Die allgemeine Definition der Schnittstelle (von Meriam-Webster): der Ort oder Bereich, in dem verschiedene Dinge treffen und kommunizieren mit oder gegenseitig beeinflussen. Wenn Sie statischen Komponenten einer Klasse oder statische Klassen ganz weglassen, wir ignorieren große Teile davon, wie diese schlechten Jungen in Wechselwirkung treten.

Hier ist ein sehr klares Beispiel dafür, wo in der Lage zu verwenden Schnittstellen mit statischen Klassen wäre sehr nützlich: 

public interface ICrudModel<T, Tk>
{
    Boolean Create(T obj);
    T Retrieve(Tk key);
    Boolean Update(T obj);
    Boolean Delete(T obj);
}

Zur Zeit schreibe ich die statischen Klassen, die diese Methoden ohne jede Art von Kontrolle, um sicherzustellen, enthalten, dass ich nichts vergessen habe. Ist wie die schlechten alten Zeiten der Programmierung vor OOP.

C # und die CLR sollte statische Methoden in Schnittstellen wie Java unterstützt. Die statische Modifier Teil eines Vertrag Definition und Bedeutung hat, nämlich, dass das Verhalten und Rückgabewert nicht Basis auf Instanz variieren, obwohl es nach wie vor von Anruf kann variieren zu nennen.

Das heißt, ich empfehlen, dass, wenn Sie eine statische Methode in einer Schnittstelle verwenden möchten, und kann es nicht, stattdessen eine Anmerkung verwenden. Sie werden die Funktionen, die Sie suchen bekommen.

Ich denke, die kurze Antwort ist „weil es von Null Nutzen ist“. Um eine Schnittstelle Methode aufrufen, müssen Sie eine Instanz des Typs. Von Instanzmethoden können Sie alle statischen Methoden rufen Sie wollen.

Ich denke, die Frage über die Tatsache erhält, dass C # ein anderes Schlüsselwort muss, für genau diese Art von Situation. Sie wollen eine Methode, deren Rückgabewert hängt nur von der Art, auf dem sie aufgerufen wird. Sie können es nicht nennen „statisch“, wenn der Typ nicht bekannt ist. Aber sobald der Typ bekannt wird, wird es statisch geworden. „Ungelöste statisch“ ist die Idee - es ist nicht statisch, noch nicht, aber wenn wir den Empfangstyp kennen, wird es sein. Das ist ein durchaus gutes Konzept, weshalb Programmierer für sie fragen immer wieder. Aber es hat nicht ganz in die Art und Weise passen die Designer gedacht, über die Sprache.

Da es nicht möglich ist, habe ich mit nicht-statischen Methoden in der Art und Weise gezeigt unten genommen. Nicht gerade ideal, aber ich kann keinen Ansatz sehen, dass mehr Sinn macht, zumindest nicht für mich. 

public interface IZeroWrapper<TNumber> {
  TNumber Zero {get;}
}

public class DoubleWrapper: IZeroWrapper<double> {
  public double Zero { get { return 0; } }
}
  

Wie pro Objektorientiertes Konzept Schnittstelle von Klassen implementiert und   hat Vertrag diese implementierte Funktion (oder Methoden) für den Zugriff auf mit   Objekt.

Also, wenn Sie wollen Schnittstelle Vertrag Methoden zugreifen müssen Sie Objekt erstellen. Es wird immer muss das nicht bei statischen Methoden erlaubt. Statische Klassen, Methoden und Variablen nie ohne diesen Bereich Objekt zu schaffen, in Speicherobjekte und Last erfordern (oder Klasse) oder Sie können nicht sagen, Objekterstellung benötigen.

Konzeptionell gibt es keinen Grund, warum eine Schnittstelle keinen Vertrag definieren könnte, die statischen Methoden enthält.

Für die aktuelle Sprache C # Implementierung ist die Beschränkung auf Grund der Berücksichtigung der Vererbung einer Basisklasse und Schnittstellen. Wenn „Klasse Somebaseclass“ Geräte „Schnittstelle ISomeInterface“ und „Klasse SomeDerivedClass: Somebaseclass, ISomeInterface“ auch die Schnittstelle implementiert, um eine statische Methode eine Interface-Methode fehlschlagen würde implementieren kompiliert, da eine statische Methode nicht gleiche Signatur wie eine Instanz Methode haben kann (was würde anwesend sein in der Basisklasse, um die Schnittstelle zu implementieren).

Eine statische Klasse ist funktional identisch mit einem Singleton und dient dem gleichen Zweck wie ein Singleton mit cleaner Syntax. Da ein Singleton eine Schnittstelle implementieren kann, sind Interface-Implementierungen von Statik konzeptionell gültig.

So ist es einfach darauf an, die Begrenzung von C # Namenskonflikt zum Beispiel und statische Methoden mit dem gleichen Namen durch Vererbung. Es gibt keinen Grund, warum C # nicht „aufgerüstet“ werden könnte, um statische Methode Verträge (Schnittstellen) zu unterstützen.

tu das nicht, versuchen Sie abstrakte Klassen statt 

public abstract class ExampleBase
{
    /// <summary>
    /// Do it
    /// </summary>
    public virtual abstract static void DoIt();
}

Wenn eine Klasse eine Schnittstelle implementiert, ist es beispielsweise für die Schnittstellenelemente zu schaffen. Während ein statischer Typ tut eine Instanz hat, hat es keinen Sinn statische Signaturen in einer Schnittstelle zu haben.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top