Modello C # per gestire in modo pulito le "funzioni libere", evitando le classi statiche di "utility bag" di tipo Helper

Recentemente stavo rivedendo alcune classi statiche "utility bag" in stile Helper che fluttuavano attorno ad alcune grandi basi di codice C # con cui lavoro, cose fondamentalmente come il seguente frammento molto condensato:

// Helpers.cs

public static class Helpers
{
    public static void DoSomething() {}
    public static void DoSomethingElse() {}
}

I metodi specifici che ho esaminato sono

• per lo più estranei l'uno all'altro,
• senza stato esplicito persistito tra le invocazioni,
• piccolo e
• ciascuno consumato da una varietà di tipi non correlati.

Modifica: quanto sopra non intende essere un elenco di presunti problemi. È un elenco di caratteristiche comuni dei metodi specifici che sto esaminando. È contesto per aiutare le risposte a fornire soluzioni più pertinenti.

Proprio per questa domanda, mi riferirò a questo tipo di metodo come GLUM (metodo generale di utilità leggero). La connotazione negativa di "glum" è parzialmente intesa. Mi dispiace se questo si presenta come un gioco di parole stupido.

Anche mettendo da parte il mio scetticismo predefinito sui GLUM, non mi piacciono le seguenti cose:

• Una classe statica viene utilizzata esclusivamente come spazio dei nomi.
• L'identificatore di classe statica è sostanzialmente insignificante.
• Quando viene aggiunto un nuovo GLUM, (a) questa classe "bag" viene toccata senza motivo o (b) viene creata una nuova classe "bag" (che di solito non è un problema; ciò che è negativo è che il nuovo le classi statiche spesso ripetono semplicemente il problema di non correlazione, ma con meno metodi).
• La meta-denominazione è inevitabilmente terribile, non standard, e di solito internamente incoerente, che si tratti di Helpers, Utilitieso qualsiasi altra cosa.

Qual è un modello ragionevolmente buono e semplice per refactoring questo, preferibilmente affrontando le preoccupazioni di cui sopra e preferibilmente con un tocco il più leggero possibile?

Dovrei probabilmente enfatizzare: tutti i metodi con cui ho a che fare sono accoppiati l'uno con l'altro. Non sembra esserci un modo ragionevole per scomporli in borse di metodi di classe statica a grana fine ma ancora multi-membro.

Penso che tu abbia due problemi strettamente collegati tra loro.

• Le classi statiche contengono funzioni logicamente non correlate
• I nomi delle classi statiche non forniscono informazioni utili sul significato / contesto delle funzioni contenute.

Questi problemi possono essere risolti combinando solo metodi logicamente correlati in una classe statica e spostando gli altri nella propria classe statica. In base al dominio del problema, tu e il tuo team dovreste decidere quali criteri userete per separare i metodi in classi statiche correlate.

Preoccupazioni e possibili soluzioni

I metodi sono per lo più non correlati tra loro - problema. Combina i metodi correlati in una classe statica e sposta i metodi non correlati nelle proprie classi statiche.

I metodi sono senza stato esplicito persistente tra le invocazioni - non è un problema. I metodi senza stato sono una caratteristica, non un bug. Lo stato statico è comunque difficile da testare e dovrebbe essere utilizzato solo se è necessario mantenere lo stato attraverso le invocazioni del metodo, ma esistono modi migliori per farlo come le macchine a stati e la yieldparola chiave.

I metodi sono piccoli - non è un problema. - I metodi dovrebbero essere piccoli.

I metodi sono ciascuno consumato da una varietà di tipi non correlati - non è un problema. Hai creato un metodo generale che può essere riutilizzato in molti luoghi non correlati.

Una classe statica viene utilizzata esclusivamente come spazio dei nomi , non un problema. Ecco come vengono utilizzati i metodi statici. Se questo stile di metodi di chiamata ti dà fastidio, prova a utilizzare i metodi di estensione o la using staticdichiarazione.

L'identificatore di classe statico è sostanzialmente insignificante - problema . Non ha senso perché gli sviluppatori stanno inserendo metodi non correlati. Inserisci i metodi non correlati nelle loro classi statiche e dai loro nomi specifici e comprensibili.

Quando viene aggiunto un nuovo GLUM, (a) questa classe "bag" viene toccata (tristezza SRP) - non è un problema se si segue l'idea che solo i metodi logicamente correlati dovrebbero essere in una classe statica. SRPnon è violato qui, perché il principio dovrebbe essere applicato per le classi o per i metodi. La singola responsabilità delle classi statiche significa contenere metodi diversi per una "idea" generale. Quell'idea può essere una funzione o una conversione, o iterazioni (LINQ), normalizzazione o convalida dei dati ...

o meno frequentemente (b) viene creata una nuova classe "bag" (più bag) - non è un problema. Classi / classi / funzioni statiche: sono i nostri strumenti (per sviluppatori) che utilizziamo per la progettazione di software. Il tuo team ha dei limiti per l'utilizzo delle lezioni? Quali sono i limiti massimi per "più borse"? La programmazione si basa sul contesto, se per la soluzione nel tuo particolare contesto si arriva a 200 classi statiche che comprensibilmente denominate, logicamente collocate in spazi dei nomi / cartelle con gerarchia logica - non è un problema.

La meta-nomenclatura è inevitabilmente terribile, non standard e di solito incoerente internamente, sia che si tratti di Helpers, Utilities o qualsiasi altra cosa - problema. Fornire nomi migliori che descrivono il comportamento previsto. Mantenere solo i metodi correlati in una classe, che forniscono assistenza per una migliore denominazione.

Abbraccia la convenzione secondo cui le classi statiche vengono utilizzate come spazi dei nomi in situazioni come questa in C #. Gli spazi dei nomi ottengono buoni nomi, così dovrebbero essere queste classi. La using staticfunzione di C # 6 rende anche la vita un po 'più semplice.

Nomi di classi puzzolenti come Helperssegnalano che i metodi dovrebbero essere suddivisi in classi statiche meglio denominate, se possibile, ma uno dei tuoi presupposti enfatizzati è che i metodi con cui hai a che fare sono "non accoppiati", il che implica la suddivisione in una nuova classe statica per metodo esistente. Probabilmente va bene, se

• ci sono buoni nomi per le nuove classi statiche e
• lo giudichi per favorire effettivamente la manutenibilità del tuo progetto.

Come esempio inventato, Helpers.LoadImagepotrebbe diventare qualcosa di simile FileSystemInteractions.LoadImage.

Tuttavia, potresti finire con i metodi-bag di classe statica. Alcuni modi in cui ciò può accadere:

• Forse solo alcuni (o nessuno) dei metodi originali hanno buoni nomi per le loro nuove classi.
• Forse le nuove classi in seguito si evolveranno per includere altri metodi pertinenti.
• Forse il nome della classe originale non era maleodorante e in realtà andava bene.

È importante ricordare che questi metodi-bag di classe statica non sono terribilmente rari in basi di codice C # reali. Probabilmente non è patologico averne alcuni piccoli .

Se vedi davvero un vantaggio nell'avere ogni metodo simile a una "funzione libera" nel suo file (il che va bene e vale la pena se giudichi onestamente che effettivamente benefici la manutenibilità del tuo progetto), potresti prendere in considerazione l'idea di rendere tale classe statica anziché statica classe parziale, impiegando il nome della classe statica simile a come si farebbe con uno spazio dei nomi e quindi utilizzandolo tramite using static. Per esempio:

Program.cs

namespace ConsoleApp1
{
    using static Foo;
    using static Flob;

    class Program
    {
        static void Main(string[] args)
        {
            Bar();
            Baz();
            Wibble();
            Wobble();
        }
    }
}

Foo / Bar.cs

namespace ConsoleApp1
{
    static partial class Foo
    {
        public static void Bar() { }
    }
}

Foo / Baz.cs

namespace ConsoleApp1
{
    static partial class Foo
    {
        public static void Baz() { }
    }
}

Flob / Wibble.cs

namespace ConsoleApp1
{
    static partial class Flob
    {
        public static void Wibble() { }
    }
}

Flob / Wobble.cs

namespace ConsoleApp1
{
    static partial class Flob
    {
        public static void Wobble() { }
    }
}

Generalmente non dovresti avere o richiedere alcun "metodo generale di utilità". Nella tua logica aziendale. Dai un'altra occhiata e mettili in un posto adatto.

Se stai scrivendo una libreria matematica o qualcosa del genere, suggerirei, anche se normalmente li odio, metodi di estensione.

È possibile utilizzare i metodi di estensione per aggiungere funzioni ai tipi di dati standard.

Ad esempio, diciamo che ho una funzione generale MySort () invece di Helpers.MySort o l'aggiunta di un nuovo ListOfMyThings.MySort posso aggiungerlo a IEnumerable