Что такое помощник? Это шаблон дизайна? Это алгоритм?

Может быть, немного насмешливо, но так как я не могу найти этот ответ нигде в Google, чтобы убедиться, что у Software Engineering есть ответ:

Что такое помощник?

Я видел, как имя используется везде (имена модулей, имена классов, имена методов), как будто семантика была глубокой и содержательной, но в контексте компьютерных наук (хотя у меня нет степени в этом), я ' никогда не видел ни описания, ни определения!

Это шаблон дизайна? Это алгоритм? Однажды я работал над программой, в которой модуль и класс назывались somethingsomethinghelper (где somethingsomething тоже было довольно общим), и я быстро переименовал его в нечто, что имело смысл для меня, но я чувствую, что здесь что-то упущено!

Класс Helper - это менее известный запах кода, когда кодировщик идентифицировал некоторые разные, часто используемые операции и пытался сделать их многократно используемыми, объединив их в неестественную группу. Затем последующие разработчики пришли в проект и не поняли, что класс помощников существует, и, следовательно, переписали те же самые общие операции или даже создали больше классов помощников.

А если серьезно, то основная проблема с классами Helper заключается в том, что они, как правило, представляют собой операции, которые действуют на определенный класс, что, очевидно, означает, что в терминах ОО они страдают от острого случая зависти к функциям . Эта неспособность связать поведение с данными, на которые он воздействует, является причиной того, что разработчики так часто (по моему опыту) не могут его найти.

В дополнение к этому, как вы уже определили, 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; }
    }
}

Моя компания использовала методологию базового класса / вспомогательного класса, где у каждого объекта было бы два класса. У вас будет класс Person, который содержит все свойства и определения класса, и класс PersonHelper, который содержит все методы, операторы SQL и Logic, которые манипулируют классом Person. Это хорошо сработало для нас, потому что все наши приложения используют операторы SQL для манипулирования данными, и нам было очень легко находить и изменять операторы SQL по мере необходимости.

С тех пор мы пошли дальше и теперь поместили все в класс Person / Base. Мы прекратили использовать соглашение об именах Helper, потому что хотели, чтобы в наших проектах было меньше файлов. Кроме того, длина некоторых имен классов вышла из-под контроля. смешно.

Не хороший пример, но вы поняли идею.

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

Я не говорю, что использование соглашения о присвоении имен является идеальным решением, но оно работало для нас в течение нескольких лет.