Metodi di estensione vs. Metodi di classe statica

Penso che i metodi di estensione siano più "individuabili". Se ho un determinato tipo, Intelli-sense mi fornirà automaticamente i metodi di estensione.

Quando una classe e un metodo statici, devo conoscere il nome della classe statica in modo che possa farvi riferimento. Nei progetti di piccole dimensioni, questo potrebbe non fare la differenza, ma questi progetti più grandi con diverse directory e molti file diversi, un metodo di estensione potrebbe essere più facile da scoprire e utilizzare per qualcuno di nuovo.

Il grande guadagno per extension methods è che ti permettono di aggiungere funzionalità aggiuntive a .Net Framework o classi di terze parti per cui non hai il codice sorgente o non puoi altrimenti modificare.

Ad esempio

public static class MyStringExtender
{
    /// <summary>
    /// Convert a string to a byte array using Ascii encoding
    /// </summary>
    /// <param name="source"></param>
    /// <returns></returns>
    public static byte[] AsciiToByteArray(this string source)
    {
        return string.IsNullOrEmpty(source)
                   ? new byte[0]
                   : new ASCIIEncoding().GetBytes(source);
    }
}

Non esiste uno standard del settore in merito all'utilizzo dei metodi di estensione o delle classi statiche. Onestamente, "i metodi di estensione" sono nelle classi statiche. Questo è un caso in cui i progettisti di linguaggio di C # ci permettono di avere la nostra torta, e mangiarla a.

Supponiamo che tu abbia una tradizionale classe statica "utils":

public static class AppUtils
{
    public static string ToStandardDateFormat(DateTime date)
    {
        // ... logic to format dates application-wide
    }
}

Non è così male. Puoi vedere @AppUtils.ToStandardDateFormat(someDate) in un gruppo di modelli di rasoio. Abbastanza standard in applicazioni in tutti gli stack tecnologici. Con ulteriori 5 caratteri di codice, puoi fare entrambe le cose:

public static class AppUtils
{
    public static string ToStandardDateFormat(this DateTime date)
    {
        // ... logic to format dates application-wide
    }
}

Ora puoi fare:

@AppUtils.ToStandardDateFormat(someDate)
@someDate.ToStandardDateFormat()

Non ci sono linee guida. Nessun standard Lancia una moneta in molti casi. Testa o croce, quindi torna alla codifica.

Il più grande vantaggio per me è la leggibilità.

Considerare per un momento una tipica istruzione LINQ che utilizza il concatenamento del metodo:

var total = myList.Where(x => x.num > 5)
                  .Select(x => x.num)
                  .Distinct()
                  .Aggregate((total, next) => total + next);

Piuttosto facile da leggere. Ma potresti usare i metodi statici per fare la stessa cosa.

var total = Enumerable.Aggregate(Enumerable.Distinct(Enumerable.Select(Enumerable.Where(myList, x => x.num > 5), x.num)), (total, next) => total + next);

E anche se lo formattassi un po ':

var total = Enumerable.Aggregate(
                Enumerable.Distinct(
                    Enumerable.Select(
                        Enumerable.Where(myList, x => x.num > 5)
                       , x.num)
                    )
               , (total, next) => total + next);

È ancora difficile da leggere. I lamda sono molto lontani dai nomi delle funzioni con cui vanno. Diventa piuttosto difficile districarlo e capire cosa sta realmente accadendo. La versione concatenata del metodo è molto più facile da leggere (almeno per me).

Scegli ciò che rende il codice più facile da leggere e utilizzare. Se un'operazione può essere applicabile a un oggetto nella maggior parte o in qualsiasi contesto, andrei con un metodo di estensione (trasformazioni, formattazione, ecc.) Se è applicabile solo in un determinato contesto, vai con metodi statici ( InterestCalculator.CalculateInterest(decimal principle, decimal interestRatePerMonth, int numberOfMonths) farebbe un metodo di estensione scadente per decimali o interi).