it-swarm.com.de

Warum lässt C # keine statischen Methoden zur Implementierung einer Schnittstelle zu?

Warum wurde C # so entworfen?

Soweit ich es verstehe, beschreibt eine Schnittstelle nur das Verhalten und dient dazu, eine vertragliche Verpflichtung für Klassen zu beschreiben, die die Schnittstelle implementieren, wobei ein bestimmtes Verhalten implementiert wird.

Wenn Klassen dieses Verhalten in einer gemeinsamen Methode implementieren möchten, warum sollten sie es nicht tun?

Hier ist ein Beispiel von dem, was ich vorhabe:

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

    ....

 }
423
Kramii

Angenommen, Sie fragen, warum Sie das nicht tun können:

public interface IFoo {
    void Bar();
}

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

Das macht für mich keinen Sinn, semantisch. Auf einer Schnittstelle angegebene Methoden sollten vorhanden sein, um den Vertrag für die Interaktion mit einem Objekt anzugeben. Mit statischen Methoden können Sie nicht mit einem Objekt interagieren. Wenn Sie sich in der Position befinden, in der Ihre Implementierung statisch gemacht werden könnte, müssen Sie sich möglicherweise fragen, ob diese Methode wirklich in das Interface gehört.


Um Ihr Beispiel zu implementieren, würde ich Animal eine const -Eigenschaft geben, die immer noch aus einem statischen Kontext heraus auf sie zugreifen kann, und diesen Wert in der Implementierung zurückgeben.

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

In einer komplizierteren Situation können Sie immer eine andere statische Methode deklarieren und diese delegieren. Beim Versuch, ein Beispiel zu finden, fiel mir kein Grund ein, warum Sie sowohl im statischen als auch im instanziellen Kontext etwas Nicht-Triviales tun würden. Daher erspare ich Ihnen einen FooBar-Blob und nehme dies als Hinweis darauf, dass dies möglich ist keine gute Idee sein.

209

Mein (vereinfachter) technischer Grund ist, dass sich statische Methoden nicht in der vtable befinden und die Aufrufseite zur Kompilierzeit ausgewählt wird. Dies ist der gleiche Grund, aus dem Sie keine übergeordneten statischen Member überschreiben können. Für weitere Details benötigen Sie einen CS-Absolvent oder einen Compiler-Wonk - von dem ich auch nicht bin.

Aus politischen Gründen werde ich Eric Lippert zitieren (der ein Compiler ist und einen Bachelor in Mathematik, Informatik und Angewandter Mathematik der University of Waterloo hat (Quelle: LinkedIn ): 

... das Kerndesignprinzip der statischen Methoden, das Prinzip, das ihnen ihren Namen gibt ... [ist] ... es kann immer genau bestimmt werden, zu welcher Kompilierzeit die Methode aufgerufen wird. Das heißt, die Methode kann nur durch statische Analyse des Codes aufgelöst werden.

Beachten Sie, dass Lippert Platz für eine sogenannte Typmethode lässt:

Das heißt, eine mit einem Typ verknüpfte Methode (wie ein statischer Typ), die kein Argument "this" (nicht im Gegensatz zu einer Instanz oder einem virtuellen Objekt) akzeptiert, sondern eine, bei der die aufgerufene Methode vom konstruierten Typ von T ( im Gegensatz zu einem statischen Element, das zur Kompilierzeit bestimmbar sein muss).

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

161
Mark Brackett

Die meisten Antworten scheinen den ganzen Punkt zu übersehen. Polymorphismus kann nicht nur zwischen Instanzen, sondern auch zwischen Typen verwendet werden. Dies ist häufig erforderlich, wenn wir Generika verwenden.

Nehmen wir an, wir haben Typparameter in der generischen Methode und müssen einige Operationen damit ausführen. Wir möchten nicht instantinieren, weil wir die Konstruktoren nicht kennen. 

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ässlichen" Alternativen aufwarten:

  • Reflection verwenden Hässlich und schlägt die Idee von Schnittstellen und Polymorphismus.

  • vollständig getrennte Werksklasse erstellen

    Dies kann die Komplexität des Codes erheblich erhöhen. Wenn wir beispielsweise versuchen, Domänenobjekte zu modellieren, würde jedes Objekt eine andere Repository-Klasse benötigen.

  • Instanziieren und dann die gewünschte Schnittstellenmethode aufrufen

    Dies kann schwierig zu implementieren sein, auch wenn wir die Quelle für die Klassen steuern, die als generische Parameter verwendet werden. Der Grund ist, dass wir zum Beispiel benötigen, dass die Instanzen nur im bekannten Zustand "Verbunden mit DB" sind. 

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 zur Lösung des Problems der statischen Schnittstelle zu verwenden, müssen wir Folgendes 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...
    }
  }
}

Dies ist offensichtlich hässlich und macht den Code für alle anderen Methoden unnötig. Natürlich auch keine elegante Lösung!

86

Ich weiß, dass es eine alte Frage ist, aber es ist interessant. Das Beispiel ist nicht das Beste. Ich denke, es wäre viel klarer, wenn Sie einen Anwendungsfall zeigen würden:

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

Nur statische Methoden haben zu können implementieren Eine Schnittstelle würde nicht das erreichen, was Sie wollen. Was wäre nötig, um statische Mitglieder zu haben teil einer Schnittstelle. Ich kann mir sicherlich viele Anwendungsfälle vorstellen, vor allem wenn es darum geht, Dinge zu erstellen. Ich könnte zwei Ansätze anbieten, die hilfreich sein könnten:

  1. Erstellen Sie eine statische generische Klasse, deren type-Parameter der Typ ist, den Sie an DoSomething weitergeben würden. Jede Variation dieser Klasse enthält ein oder mehrere statische Member, die sich auf diesen Typ beziehen. Diese Informationen könnten bereitgestellt werden, indem entweder jede interessierende Klasse eine "Registerinformation" -Routine aufruft oder indem Reflection verwendet wird, um die Informationen zu erhalten, wenn der statische Konstruktor der Klassenvariation ausgeführt wird. Ich glaube, der letztere Ansatz wird von Dingen wie Comparer <T> .Default () ..__ verwendet.
  2. Definieren Sie für jede interessierende Klasse T eine Klasse oder Struktur, die IGetWhateverClassInfo <T> implementiert und eine "neue" Bedingung erfüllt. Die Klasse enthält zwar keine Felder, hat jedoch eine statische Eigenschaft, die ein statisches Feld mit den Typinformationen zurückgibt. Übergeben Sie den Typ dieser Klasse oder Struktur an die betreffende generische Routine, die eine Instanz erstellen kann, um Informationen über die andere Klasse abzurufen. Wenn Sie zu diesem Zweck eine Klasse verwenden, sollten Sie wahrscheinlich eine statische generische Klasse wie oben angegeben definieren, um nicht jedes Mal eine neue Descriptor-Objekt-Instanz erstellen zu müssen. Wenn Sie eine Struktur verwenden, sollten die Kosten für die Instantiierung gleich Null sein. Für jeden anderen Strukturtyp ist jedoch eine andere Erweiterung der DoSomething-Routine erforderlich.

Keiner dieser Ansätze ist wirklich ansprechend. Andererseits würde ich erwarten, dass .net, wenn die Mechanismen in CLR vorhanden wären, um diese Art von Funktionalität sauber bereitzustellen, parametrisierte "neue" Bedingungen angeben kann (da bekannt zu sein scheint, ob eine Klasse einen Konstruktor mit einer bestimmten Signatur hat) vergleichbar mit der Schwierigkeit, zu wissen, ob es eine statische Methode mit einer bestimmten Signatur gibt).

18
supercat

Schnittstellen legen das Verhalten eines Objekts fest.

Statische Methoden geben kein Verhalten eines Objekts an, sondern Verhalten, das sich auf ein Objekt auswirkt.

14
John Kraft

In dem Maße, in dem Schnittstellen "Verträge" darstellen, scheint es für statische Klassen durchaus sinnvoll, Schnittstellen zu implementieren. 

Die obigen Argumente scheinen diesen Punkt in Bezug auf Verträge zu übersehen.

13
George

Kurzsichtigkeit, würde ich vermuten.

Wenn ursprünglich entworfen, sollten Schnittstellen nur mit Instanzen von Klassen verwendet werden

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

Erst mit der Einführung von Interfaces als Einschränkungen für Generics war das Hinzufügen einer statischen Methode zu einem Interface praktisch anwendbar.

(Antwort auf Kommentar :) Ich glaube, dass eine Änderung jetzt die CLR ändern müsste, was zu Inkompatibilitäten mit vorhandenen Baugruppen führen würde.

13
James Curran

Da der Zweck einer Schnittstelle darin besteht, Polymorphismus zuzulassen, können Sie eine Instanz einer beliebigen Anzahl definierter Klassen übergeben, die alle definiert wurden, um die definierte Schnittstelle zu implementieren. Dadurch wird sichergestellt, dass der Code innerhalb Ihres polymorphen Aufrufs gefunden wird die Methode, die Sie anrufen. Es macht keinen Sinn, eine statische Methode zur Implementierung der Schnittstelle zuzulassen. 

Wie würdest du 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;  
9
Charles Bretana

In Bezug auf statische Methoden, die in nicht generischen Kontexten verwendet werden, stimme ich zu, dass es nicht sinnvoll ist, sie in Schnittstellen zuzulassen, da Sie sie nicht aufrufen könnten, wenn Sie ohnehin einen Verweis auf die Schnittstelle hätten. Es gibt jedoch ein grundlegendes Loch im Sprachentwurf, der durch die Verwendung von Schnittstellen NICHT in einem polymorphen Kontext, sondern in einem generischen Kontext erstellt wird. In diesem Fall ist die Schnittstelle überhaupt keine Schnittstelle, sondern eher eine Einschränkung. Da C # kein Konzept für eine Einschränkung außerhalb einer Schnittstelle hat, fehlen wesentliche Funktionen. Fallbeispiel:

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

Hier gibt es keinen Polymorphismus. Das Generic verwendet den tatsächlichen Typ des Objekts und ruft den Operator + = auf. Dies schlägt jedoch fehl, da es nicht sicher sagen kann, dass dieser Operator existiert. Die einfache Lösung besteht darin, sie in der Einschränkung anzugeben. Die einfache Lösung ist nicht möglich, da Operatoren statisch sind und statische Methoden nicht in einer Schnittstelle enthalten sein können. In diesem Fall werden Einschränkungen als Schnittstellen dargestellt.

Was C # benötigt, ist ein echter Einschränkungstyp. Alle Schnittstellen wären auch Einschränkungen, aber nicht alle Einschränkungen wären Schnittstellen. Dann könnten Sie Folgendes 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 wurde bereits viel darüber gesprochen, eine IArithmetik für alle numerischen Typen zu implementieren, aber es gibt Bedenken hinsichtlich der Effizienz, da eine Einschränkung kein polymorphes Konstrukt ist. Eine CArithmetische Einschränkung würde dieses Problem lösen.

4
Jeremy Sorensen

Was Sie anscheinend wünschen, lässt zu, dass eine statische Methode sowohl über den Typ als auch über eine Instanz dieses Typs aufgerufen wird. Dies würde zumindest zu Mehrdeutigkeiten führen, die nicht wünschenswert sind.

Es würde endlose Debatten darüber geben, ob es eine Rolle spielte, welche bewährten Praktiken es ist und ob Leistungsprobleme auf die eine oder andere Weise auftreten. Indem wir es einfach nicht unterstützen, können wir uns mit C # keine Sorgen mehr machen.

Es ist auch wahrscheinlich, dass ein Compilier, der diesem Wunsch entspricht, einige Optimierungen verliert, die mit einer strengeren Trennung zwischen Instanz- und statischen Methoden einhergehen.

3
AnthonyWJones

Sie können sich die statischen Methoden und die nicht statischen Methoden einer Klasse als unterschiedliche Schnittstellen vorstellen. Beim Aufruf werden statische Methoden in das statische Singleton-Klassenobjekt aufgelöst und nicht statische Methoden in die Instanz der Klasse, mit der Sie sich befassen. Wenn Sie also statische und nicht statische Methoden in einer Schnittstelle verwenden, würden Sie tatsächlich zwei Schnittstellen deklarieren, wenn Sie wirklich möchten, dass Schnittstellen für den Zugriff auf eine zusammenhängende Sache verwendet werden.

3
Scott Langham

Um ein Beispiel zu geben, bei dem mir entweder die statische Implementierung von Schnittstellenmethoden fehlt oder was Mark Brackett als "sogenannte Typmethode" eingeführt hat:

Beim Lesen aus einem Datenbankspeicher verfügen wir über eine generische DataTable-Klasse, die das Lesen aus einer Tabelle einer beliebigen Struktur übernimmt. Alle tabellenspezifischen Informationen werden in eine Klasse pro Tabelle eingefügt, die auch Daten für eine Zeile aus der Datenbank enthält und eine IDataRow-Schnittstelle implementieren muss. In IDataRow ist eine Beschreibung der Struktur der Tabelle enthalten, die aus der Datenbank gelesen werden soll. Die DataTable muss vor dem Lesen aus der DB die Datenstruktur von der IDataRow abfragen. Derzeit sieht das so aus:

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 für jede zu lesende Tabelle benötigt. Der Aufwand für die Instanziierung einer weiteren Instanz ist minimal. In diesem Fall wäre es jedoch nett.

3
Jesper Grooss

Weil sich Schnittstellen in einer Vererbungsstruktur befinden und statische Methoden nicht gut erben.

3
Joel Coehoorn

Die meisten Leute scheinen zu vergessen, dass Klassen in OOP auch Objekte sind, und daher haben sie Meldungen, die aus irgendeinem Grund "statische Methode" nennen. Die Tatsache, dass Unterschiede zwischen Instanzobjekten und Klassenobjekten bestehen, zeigt nur Fehler oder Mängel in der Sprache . Optimist über C # obwohl ...

1
Mar Bar

Schnittstellen sind abstrakte Mengen definierter verfügbarer Funktionen.

Ob sich eine Methode in dieser Schnittstelle als statisch verhält oder nicht, ist ein Implementierungsdetail, das hinter der Schnittstelle verborgen werden sollte. Es wäre falsch, eine Schnittstellenmethode als statisch zu definieren, da Sie die Methode unnötigerweise auf bestimmte Weise implementieren müssen.

Wenn Methoden als statisch definiert würden, wäre die Klasse, die das Interface implementiert, nicht so gekapselt, wie es sein könnte. Kapselung ist eine gute Sache, die man in objektorientiertem Design anstreben sollte (ich werde nicht auf den Grund eingehen, das kann man hier lesen: http://en.wikipedia.org/wiki/Object-oriented ) Aus diesem Grund sind statische Methoden in Schnittstellen nicht zulässig.

1
Scott Langham

Statische Klassen sollten dazu in der Lage sein, damit sie generisch verwendet werden können. Ich musste stattdessen ein Singleton implementieren, um die gewünschten Ergebnisse zu erzielen.

Ich hatte eine Reihe von statischen Business-Layer-Klassen, die CRUD-Methoden wie "Erstellen", "Lesen", "Aktualisieren", "Löschen" für jeden Entitätstyp wie "Benutzer", "Team" usw. implementierten Steuerelement mit einer abstrakten Eigenschaft für die Business Layer-Klasse, die die CRUD-Methoden implementiert hat. Dadurch konnte ich die Operationen "Erstellen", "Lesen", "Aktualisieren" und "Löschen" aus der Basisklasse automatisieren. Ich musste wegen der statischen Einschränkung ein Singleton verwenden.

1
Louis Rebolloso

C # und die CLR sollten wie Java statische Methoden in Schnittstellen unterstützen. Der statische Modifizierer ist Teil einer Vertragsdefinition und hat eine Bedeutung, insbesondere, dass das Verhalten und der Rückgabewert nicht von Instanz zu Instanz variieren, obwohl sie von Aufruf zu Aufruf noch variieren kann.

Das heißt, ich empfehle, dass, wenn Sie eine statische Methode in einer Schnittstelle verwenden möchten und nicht können, stattdessen eine Anmerkung verwenden. Sie erhalten die Funktionalität, nach der Sie suchen.

1

Zu Ihrer Information: Möglicherweise erhalten Sie ein ähnliches Verhalten, wenn Sie Erweiterungsmethoden für die Schnittstelle erstellen. Die Erweiterungsmethode wäre ein gemeinsames, nicht überschreibbares statisches Verhalten. Leider ist diese statische Methode nicht Vertragsbestandteil.

1
Daniel Auger

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

Ein Interface sollte ein Deskriptor des Klassen-Interfaces sein - oder wie es damit interagiert, und das sollte statische Interaktionen beinhalten. Die allgemeine Definition der Schnittstelle (von Meriam-Webster): der Ort oder Bereich, an dem verschiedene Dinge aufeinander treffen und miteinander kommunizieren oder sich gegenseitig beeinflussen. Wenn Sie statische Komponenten einer Klasse oder statische Klassen vollständig weglassen, ignorieren wir große Teile der Interaktion dieser bösen Jungs.

Hier ist ein sehr anschauliches Beispiel dafür, wo Schnittstellen mit statischen Klassen verwendet werden können, sehr nützlich: 

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

Derzeit schreibe ich die statischen Klassen, die diese Methoden enthalten, ohne zu prüfen, ob ich nichts vergessen habe. Ist wie die schlechten alten Tage des Programmierens vor OOP.

1
Thomas Phaneuf

Ich denke, die kurze Antwort lautet "weil es keinen Nutzen hat". Zum Aufrufen einer Schnittstellenmethode benötigen Sie eine Instanz des Typs. Von Instanzmethoden aus können Sie beliebige statische Methoden aufrufen, die Sie möchten.

0
mackenir

mach das nicht, versuche stattdessen abstrakte Klassen

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

Konzeptionell Es gibt keinen Grund, warum eine Schnittstelle keinen Vertrag definieren könnte, der statische Methoden enthält.

Für die aktuelle Implementierung der C # -Sprache ist die Einschränkung auf die Erlaubnis der Vererbung einer Basisklasse und von Schnittstellen zurückzuführen. 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 in der Basisklasse vorhanden sein, um die Schnittstelle zu implementieren).

Eine statische Klasse ist funktional mit einem Singleton identisch und dient demselben Zweck wie ein Singleton mit klarerer Syntax. Da ein Singleton eine Schnittstelle implementieren kann, sind Schnittstellenimplementierungen nach Statik konzeptionell gültig.

Es läuft also einfach auf die Beschränkung des C # -Namenskonflikts und auf statische Methoden mit demselben Namen über die Vererbung hinaus hinaus. Es gibt keinen Grund, warum C # nicht "aktualisiert" werden konnte, um statische Methodenverträge (Schnittstellen) zu unterstützen.

0
Greg McPherran

OK, hier ist ein Beispiel für die Verwendung einer 'Typmethode'. Ich erstelle eine aus einer Reihe von Klassen, die auf einem Quell-XML basieren. Also ich habe eine 

  static public bool IsHandled(XElement xml)

funktion, die wiederum in jeder Klasse aufgerufen wird.

Die Funktion sollte statisch sein, da wir sonst keine Zeit damit verbringen, unangemessene Objekte zu erstellen ..

Es wäre schön, es der Schnittstelle hinzuzufügen, um Klassenimplementierer zur Implementierung zu zwingen. Dies würde keinen erheblichen Overhead verursachen - es ist nur eine Überprüfung der Kompilierungs-/Verknüpfungszeit und hat keinen Einfluss auf die vtable.

Dies wäre jedoch auch eine geringfügige Verbesserung. Da die Methode statisch ist, muss ich als Aufrufer sie explizit aufrufen und daher sofort einen Kompilierungsfehler erhalten, wenn sie nicht implementiert ist. Eine Angabe auf der Schnittstelle zuzulassen, würde bedeuten, dass dieser Fehler etwas früher im Entwicklungszyklus auftritt. Dies ist jedoch im Vergleich zu anderen Problemen mit der unterbrochenen Schnittstelle trivial.

Es handelt sich also um ein geringfügiges potenzielles Merkmal, das am besten wahrscheinlich weggelassen wird.

0

Wenn eine Klasse eine Schnittstelle implementiert, erstellt sie eine Instanz für die Schnittstellenmitglieder. Während ein statischer Typ keine Instanz hat, hat es keinen Sinn, statische Signaturen in einer Schnittstelle zu haben.

0
Vinay Chanumolu

Gemäß objektorientiertem Konzept Schnittstelle, die von Klassen und .__ implementiert wird. haben einen Vertrag, um auf diese implementierten Funktionen (oder Methoden) mit .__ zuzugreifen. Objekt.

Wenn Sie also auf Interface Contract-Methoden zugreifen möchten, müssen Sie ein Objekt anlegen. Es ist immer ein Muss, dass bei statischen Methoden nicht erlaubt ist. Statische Klassen, Methoden und Variablen erfordern niemals Objekte und laden in den Speicher, ohne ein Objekt dieses Bereichs (oder dieser Klasse) zu erstellen.

0

Ich denke, die Frage kommt auf die Tatsache an, dass C # für genau diese Situation ein anderes Keyword benötigt. Sie möchten eine Methode, deren Rückgabewert nur von dem Typ abhängt, für den sie aufgerufen wird. Sie können es nicht "statisch" nennen, wenn der Typ unbekannt ist. Sobald der Typ bekannt ist, wird er statisch. "Ungelöst statisch" ist die Idee - sie ist noch nicht statisch, aber sobald wir den Empfangstyp kennen, wird es der Fall sein. Dies ist ein absolut gutes Konzept, weshalb Programmierer ständig danach fragen. Es passte jedoch nicht ganz in das Denken der Designer über die Sprache.

Da es nicht verfügbar ist, habe ich mich für die Verwendung nicht-statischer Methoden wie unten gezeigt entschieden. Nicht gerade ideal, aber ich sehe keinen Ansatz, der sinnvoller ist, jedenfalls nicht für mich.

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

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