Usa troppi metodi di estensione anti-pattern?

6

Lo zucchero sintattico fornito dai metodi di estensione può creare dipendenza.

Prendi ad esempio

public void TagNode(SiteMapNode childNode, string url, string title)
{
  //do stuff
}

vs

public static void Tag(this SiteMapNode source, string url, string title)
{
  //do stuff
}

e l'uso:

TagNode(myNode, myUrl, myTitle);

vs

myNode.Tag(myUrl, myTitle);

Puoi vedere e sentire lo zucchero, e dopo aver creato l'estensione c'è meno digitamento.

Ma mi chiedo se può andare troppo lontano e come giudicare cosa è troppo lontano e questo è un anti-pattern noto?

Se si tratta di un anti-pattern ma non ha un nome, lo chiamerei:

L' hyper-extension anti-pattern.

    
posta toddmo 30.08.2016 - 01:11
fonte

3 risposte

4

I metodi di estensione sono molto utili per creare interfacce leggere . L'esempio prototipo di IEnumerable ha solo 1 membro. Tutte le funzionalità dei metodi di estensione si applicano al tuo class ExoticContainer<T> : IEnumerable<T> senza ulteriore sforzo.

I metodi di estensione sono meno appropriati per le classi che controlli, dove devi semplicemente aggiungerle come metodi normali.

Nel mezzo, dove hai una classe da un'altra parte, diventa una scelta di stile tra le sintassi TagNode(myNode, myUrl, myTitle); e myNode.Tag(myUrl, myTitle); . Entrambi gli stili sono ugualmente validi, ma attaccare con uno o l'altro è preferibile ad una miscela.

    
risposta data 30.08.2016 - 11:00
fonte
2
  1. Prendere una funzione privata e renderla pubblica di solito non è l'ideale.
  2. Se utilizzi così poco di una classe che puoi creare molti metodi di estensione, perché è una classe?
  3. Se hai intenzione di adottare un approccio più funzionale, la creazione di oggetti look orientati agli oggetti è semplicemente sciocca.

Tutto ciò detto, questo non è un anti-modello. Gli anti-pattern sono sempre dannosi. Le estensioni LINQ per IEnumerable sono un chiaro argomento contrario. L'uso eccessivo dei metodi di estensione è un odore nel peggiore dei casi.

    
risposta data 30.08.2016 - 01:28
fonte
0

Vorrei andare oltre, non mi piacciono affatto i metodi di estensione.

Se ho scritto:

Static class MyHelper {
    Static public int CountEmployees(MyCompany company) {...

Invece di

Public class MyCompany {
     Public int EmployeeCount() { ..

Non penso che nessuno direbbe che è stato un buon modello

È solo lo zucchero sintattico fornito dal compilatore a fare in modo che questi aiutanti assomiglino a metodi che ti incoraggiano a crearli del tutto.

Se hai una classe di terze parti che vuoi estendere (come ad esempio IEnumerable) ci sono altri modi per farlo. Devi davvero davvero volere che la funzione "sembra un metodo su un'altra classe" sia accompagnata da estensioni nella mia vista.

Suppongo che tu possa capire perché lo hanno fatto con IEnumerable. Aggiungere le funzionalità all'interfaccia avrebbe costretto tutti ad aggiornare tutte le loro raccolte con oggetti extra, aggiungendo nuove versioni ILinqEnumerable di qualsiasi cosa significherebbe avere entrambe le versioni in giro e gli helper statici evitare la creazione di nuovi oggetti per ogni clausola nella propria istruzione

    
risposta data 30.08.2016 - 09:10
fonte

Leggi altre domande sui tag