Що таке помічник? Це шаблон дизайну? Це алгоритм?

Можливо, трішечки, але я не можу знайти цю відповідь ніде через Google, щоб переконатися, що Software Engineering має відповідь:

Що таке помічник?

Я бачив, як назва використовується повсюдно (назви модулів, назви класів, назви методів), як би семантика була глибокою та значущою, але в контексті інформатики (хоча я не маю в ній ступеня), я ' я ніде не бачив опису чи визначення!

Це шаблон дизайну? Це алгоритм? Я колись працював над програмою, в якій і модуль, і клас називались дещо помічником ( дещо теж було досить загальним), і я негайно перейменував це на щось, що для мене мало сенс, але я відчуваю, що мені щось тут не вистачає!

Клас Helper - це менш відомий запах коду, коли кодер виявив різні, часто використовувані операції та намагався зробити їх багаторазовими, згрупуючи їх у неприродне угрупування. Потім послідовні розробники вступили в проект і не зрозуміли, що клас помічників існує, і, отже, переписали ті ж загальні операції або навіть створили більше класів Helper.

Але якщо серйозно, то головна проблема класів Helper полягає в тому, що вони, як правило, операції, які діють на конкретний клас, що, очевидно, означає, що вони означають, що вони страждають від гострого випадку Feature Envy . Ця неспроможність упакувати поведінку з тими даними, на які вона діє, тому розробники так часто (на мій досвід) не знаходять її.

На додаток до цього, як ви вже визначили SomethingSomethingHelper - це насправді жахлива назва. Це не описує, і не дає вам реального уявлення про те, які операції робить клас (це допомагає?), Що також означає, що це не очевидно при додаванні нових форм поведінки, належать вони до класу Helper чи ні. Я би розбивав такі класи за принципом пов'язаної поведінки, які логічно групуються, а потім перейменував би нові класи, щоб відобразити те, що він робить.

Помічник - це нешкідливий додатковий клас чи метод, якщо він доповнює зовнішній компонент. Якщо це робить навпаки, то він вказує на поганий дизайн, оскільки код був виключений з його повноважень, якщо взагалі є якісь повноваження.

Ось приклад нешкідливого помічника, я використовую метод під назвою, FindRepякий підраховує кількість провідних нулів.

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

Хелперний метод дуже простий, але дуже незручний для копіювання та вставлення навколо, і фреймворк не забезпечує жодного рішення.

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;
}

Ось приклад поганого помічника:

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; }
    }
}

Моя компанія використовувала методологію класу Base / Helper class, де кожен об’єкт мав би два класи. У вас був би клас Person, який містив усі властивості та визначення класу, і клас PersonHelper, який містив усі методи, оператори SQL та Logic, що маніпулювали класом Person. Це добре працювало для нас, оскільки всі наші програми використовують оператори SQL для маніпулювання даними, і нам було дуже легко знайти та змінити SQL-оператори за необхідності.

З тих пір ми продовжили рух і тепер поклали все в клас Person / Base. Ми кинули використовувати конвенцію про іменування Helper, оскільки хотіли, щоб у наших проектах було менше файлів. Також довжина деяких назв класу виходила з-під контролю. Лол.

Не чудовий приклад, але ви отримуєте ідею.

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

Я не кажу, що використання конвенції про іменування помічників є ідеальним рішенням, але воно працювало для нас протягом декількох років.