mehr Vorteile oder Nachteile zu delegieren, die Mitglieder über die klassischen Funktionen?

First off, das "high-order bit" für mich mit Bezug auf diese design-Entscheidung sein würde, dass würde ich nie tun diese Art der Sache mit einem öffentlichen Feld/Methode. Zumindest würde ich eine Eigenschaft, und wahrscheinlich nicht einmal das.

Für private Felder, benutze ich dieses Muster ist relativ Häufig, in der Regel wie diese:

class C
{
    private Func<int, int> ActualFunction = (int y)=>{ ... };
    private Func<int, int> Function = ActualFunction.Memoize();

und jetzt kann ich sehr einfach testen Sie die Leistungs-Merkmale der verschiedenen memoization Strategien, die zimmerreserviereung, ohne das Sie den text ändern, der von ActualFunction überhaupt.

Weiterer Vorteil des "Methoden-Felder der delegate-Typ" - Strategie, die Sie implementieren können code-sharing-Techniken, die anders sind als die, die wir haben "gebacken", um die Sprache. Einen geschützten Bereich der Delegaten-Typ ist im wesentlichen ein virtuelle Methode, aber mehr flexibel. Abgeleitete Klassen können ersetzen Sie es mit was Sie wollen, und Sie haben emuliert einen regelmäßigen virtuellen Methode. Aber könnten Sie bauen benutzerdefinierte inheritence Mechanismen; wenn Sie wirklich, wie die prototype-Vererbung, zum Beispiel, Sie könnten eine Konvention, dass, wenn das Feld null ist, dann eine Methode auf einige prototypische Instanz aufgerufen wird, statt, und so weiter.

Einen großen Nachteil der Methoden-sind-fields-of-delegate-Ansatz ist, dass natürlich eine überlastung nicht mehr funktioniert. Felder müssen eindeutig sein name; Methoden lediglich eindeutig sein müssen in der Signatur. Auch, Sie nicht bekommen, generische Felder, die Art und Weise, dass wir generische Methoden, also Verfahren Typrückschluss funktioniert.

, Warum Sie sollten es vermeiden, die Delegierten als Methoden standardmäßig, und was sind die alternativen:

Lernkurve

Verwendung von Stellvertretern diese Weise überrascht eine Menge Leute. Nicht jeder kann wickeln Sie Ihren Kopf um die Delegierten, oder warum würden Sie wollen, um die swap-Funktionen. Es scheint eine Lernkurve. Wenn man einmal Vergangenheit, die Delegierten scheinen einfach.

Perf und Zuverlässigkeit

Gibt es einen performance-Verlust zu Delegaten aufrufen, auf diese Weise. Dies ist ein weiterer Grund, warum ich standardmäßig die traditionelle Methode der Erklärung, es sei denn, es aktiviert etwas in mein Muster.

Gibt es auch eine Ausführung Frage der Sicherheit. Öffentliche Felder null-Werte zulassen. Wenn Sie übergeben eine Instanz einer Klasse, die mit einem öffentlichen Bereich, den Sie haben zu prüfen, dass es nicht null ist, bevor Sie es. Das schmerzt perf und ist irgendwie lahm.

Können Sie umgehen, indem Sie in allen öffentlichen Bereichen auf Eigenschaften (das ist in der Regel in allen .Net-coding-standards sowieso). Dann in den setter-Wurf ein ArgumentNullException wenn jemand versucht, zu ordnen null.

Programm-design

Selbst wenn man mit all dem umzugehen, so dass Methoden, die in der veränderlichen überhaupt geht gegen eine Menge von dem design für statische OO und funktionalen Programmiersprachen.

In statische OO-Typen sind immer statische und dynamische Verhalten wird aktiviert durch Polymorphismus. Sie kennen die genauen Verhalten eines Typs basiert auf seinen Laufzeit-Typ. Dies ist sehr hilfreich beim Debuggen eines vorhandenen Programms. Ermöglichen Sie Ihrem Typen geändert werden, die zur Laufzeit schädigt diese.

Statisch OO und Funktion Programmier-Paradigmen, zu begrenzen und zu isolieren Nebenwirkungen ist sehr hilfreich, und mit voll unveränderlich Strukturen ist eine der wichtigsten Möglichkeiten, dies zu tun. Der einzige Punkt der Freilegung Methoden als Delegierte zu erstellen veränderliche Strukturen, die das genaue Gegenteil bewirken.

Alternativen

Wenn Sie wirklich wollten, so weit zu gehen, wie immer Delegierten zu ersetzen Methoden, sollten Sie eine Sprache verwenden, wie IronPython oder etwas anderes gebaut auf der Oberseite des DLR. Diese Sprachen werden nachgerüstet und abgestimmt für den Paradigmenwechsel, den Sie versuchen zu implementieren. Benutzer und Verwalter deines Codes nicht Wundern.

Dass gesagt wird, es sind Verwendungen, rechtfertigen die Verwendung von Stellvertretern, die als Ersatz für Methoden. Sie sollten nicht erwägen diese option, es sei denn, Sie haben einen zwingenden Grund, dies zu tun, der überschreibt diese Leistung, Verwirrung, Zuverlässigkeit und design-Fragen. Sie sollten dies nur tun, wenn Sie bekommen etwas zurück.

Verwendet

• Für private Mitglieder, Eric Lippert ' s Antwort beschreibt eine gute Verwendung: (Memoization).

• Können Sie es verwenden, um implementieren eines Strategie-Musters in eine Funktion-basierte Art und Weise, anstatt dass eine Klasse Hierarchie. Wieder, die ich verwenden würde, private Mitglieder, die für dieses...

...Beispiel-code:

public class Context
{
    private Func<int, int, int> executeStrategy;

    public Context(Func<int, int, int> executeStrategy) {
        this.executeStrategy = executeStrategy;
    }

    public int ExecuteStrategy(int a, int b) {
        return executeStrategy(a, b);
    }
}

• Ich gefunden habe, einen bestimmten Fall, wo ich denke, dass die öffentliche delegieren zugesicherter Eigenschaften sind: Umsetzung einer Template Methode-Muster mit Instanzen anstelle von abgeleiteten Klassen...

...Dies ist besonders nützlich in automatisierten Integrationstests, wo Sie eine Menge von setup/tear down. In solchen Fällen ist es oft sinnvoll, die keep state -, die in einer Klasse entwickelt, um Kapseln, die Muster, anstatt verlassen sich auf die unit-test-Vorrichtung. Auf diese Weise können Sie leicht Unterstützung für das teilen von Skelett in der test-suite zwischen den Leuchten, ohne sich auf (manchmal schlechten) test-fixture-Vererbung. Es könnte auch eher für die Parallelisierung, abhängig von der Implementierung der tests.

var test = new MyFancyUITest
{
    //I usually name these things in a more test specific manner...
    Setup = () => { /* ... */ },
    TearDown = () => { /* ... */ },
};
test.Execute();

Intellisense-Unterstützung

Benutzer außerhalb der Funktion sehen Unbenannte Parameter - manchmal ist das hilfreich, obwohl es schön wäre, um in der Lage sein, Sie zu benennen.

Benannten Delegierten - ich glaube, das bekommen Sie zumindest einige Intellisense für die Parameter (wahrscheinlich nur die Namen, weniger wahrscheinlich, XML-docs - bitte korrigieren Sie mich, wenn ich falsch Liege):

public class MyClass
{
    public delegate int DoSomethingImpl(int foo, int bizBar);
    public DoSomethingImpl DoSomething = (x, y) => { return x + y; }
}

Mit einer Schließung über lokale Variablen ist eine alternative zur Verwendung einer Methode und privaten Bereichen. Ich habe eine starke Abneigung gegen Klassen mit vielen Feldern, vor allem, wenn einige dieser Felder werden nur von zwei Methoden oder weniger. In diesen Situationen, mit Hilfe eines Delegaten in ein Feld werden kann, vorzuziehen, herkömmlichen Methoden

class MyClassConventional {
  int? someValue; //When Mark() is called, remember the value so that we can do something with it in Process(). Not used in any other method.
  int X;

  void Mark() {
    someValue = X;
  }

  void Process() {
    //Do something with someValue.Value
  }
}

class MyClassClosure {
  int X;

  Action Process = null;

  void Mark() {
    int someValue = X;
    Process = () => { //Do something with someValue };
  }
}