Che cos'è un aiuto? È un modello di design? È un algoritmo?

Una classe Helper è un odore di codice meno noto in cui un codificatore ha identificato alcune operazioni varie e comunemente usate e ha tentato di renderle riutilizzabili raggruppandole in un raggruppamento innaturale. Gli sviluppatori successivi sono poi arrivati al progetto e non si sono resi conto che la classe helper esiste, e di conseguenza hanno riscritto le stesse operazioni comuni, o addirittura creato più classi Helper.

Ma seriamente, il problema principale con le classi di Helper è che di solito sono operazioni che agiscono su una classe specifica, il che significa ovviamente in termini OO che sono affetti da un caso acuto di Feature Envy . Questo fallimento nel confezionare il comportamento con i dati su cui agisce è il motivo per cui gli sviluppatori così spesso (nella mia esperienza) non riescono a trovarlo.

Oltre a questo, come hai già identificato SomethingSomethingHelper è in realtà un nome terribile. Non è descrittivo e non ti dà una vaga idea di che tipo di operazioni fa la classe (aiuta?), Il che significa anche che non è ovvio quando si aggiungono nuovi comportamenti, indipendentemente dal fatto che appartengano alla classe Helper o meno. Vorrei suddividere tali classi sulla falsariga di comportamenti correlati che si raggruppano logicamente e quindi rinominare le nuove classi per riflettere ciò che fa.

Un helper è una classe o un metodo aggiuntivo innocuo, purché sia complementare a un componente esterno. Quando fa il contrario, indica un cattivo design perché il codice è stato escluso dalla sua autorità, se esiste un'autorità.

Ecco un esempio di un helper innocuo, io uso un metodo chiamato FindRep che conta il numero di zeri iniziali.

digits = digits.Remove(0, TextHelper.FindRep('0', digits, 0, digits.Length - 2));

Il metodo helper è molto semplice, ma molto scomodo da copiare e incollare e il framework non fornisce alcuna soluzione.

public static int FindRep(char chr, string str, int beginPos, int endPos)
{
    int pos;

    for (pos = beginPos; pos <= endPos; pos++)
    {
        if (str[pos] != chr)
        {
            break;
        }
    }

    return pos - beginPos;
}

Ed ecco un esempio di cattivo aiuto:

public static class DutchZipcodeHelper
{
    public static bool Validate(string s)
    {
        return Regex.IsMatch(s, @"^[1-9][0-9]{3}[A-Z]{2}$", RegexOptions.IgnoreCase);
    }
}

public class DutchZipcode
{
    private string value;

    public DutchZipcode(string value)
    {
        if (!DutchZipcodeHelper.Validate(value))
        {
            throw new ArgumentException();
        }

        this.value = value;
    }

    public string Value
    {
        get { return value; }
    }
}

La mia azienda usava la metodologia di classe Base / Helper class in cui ogni oggetto avrebbe due classi. Avresti una classe Person che conteneva tutte le proprietà e le definizioni di classe e una classe PersonHelper che conteneva tutti i metodi, le istruzioni SQL e la logica che manipolava la classe Person. Questo ha funzionato bene per noi perché tutte le nostre applicazioni utilizzano istruzioni SQL per manipolare i dati ed è stato molto facile per noi trovare e modificare le istruzioni SQL in base alle esigenze.

Da allora siamo passati e ora mettiamo tutto nella classe Persona / Base. Abbiamo smesso di usare la convenzione di denominazione di Helper perché volevamo avere meno file nei nostri progetti. Inoltre, la lunghezza di alcuni nomi di classe stava andando fuori controllo. lol.

Non è un ottimo esempio, ma ti viene l'idea.

s = CompanyName.PersonHelper.GetPerson()
s = CompanyName.Person.GetPerson()

Non sto dicendo che usare la convenzione di denominazione degli helper sia la soluzione perfetta, ma ha funzionato per noi per alcuni anni.