Класс (классы) помощника по сравнению с функциональным наследованием. Лучшая практика

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

Если у вас есть код, который является общим только для подмножеств несвязанных команд, и создание иерархии наследования вынудило бы установить несуществующую связь, то добавление «вспомогательного» класса (нестатического, если возможно , чтобы улучшить тестируемость) было бы совершенно естественным способом решить эту проблему. Вы можете обнаружить, что можете естественным образом сгруппировать "вспомогательные" методы в отдельные классы. Например, если несколько методов должны взаимодействовать с вашей подсистемой аутентификации, у вас может быть AuthenticationMediator для этих методов. Я также не вижу никаких противоречий между тем и другим.

Вместо статических классов другой вариант - поместить общий код в новый класс и использовать внедрение зависимостей для внедрения вспомогательного класса в команды. Это также соответствует понятию композиции над наследованием.

Если есть вероятность, что дублирующая логика может понадобиться и другим классам вне иерархии, я бы поместил ее в статические вспомогательные классы. В противном случае - в базовый класс с защищенным наследованием.

На мой взгляд, я бы поместил повторяющийся код в базовый класс, если он относится только к этой иерархии классов и не будет использоваться вне ее. Если есть возможность использовать код в разных классах, переместите его во вспомогательный класс в общем проекте.

Наслаждайтесь!

Если логика работает с членами интерфейса , а не с членами реализации , то рекомендуется написать вспомогательный метод [или метод расширения].

public IRandom
{
    byte NextByte ();
}

public static class IRandomExtensions
{
    // logic that acts against public interface IRandom
    // may be applied to all implementations
    public static int GetNextUnbiasedInteger (this IRandom random) { }
    public static IEnumerable<T> Shuffle<T> (
        this IRandom random, 
        IEnumerable<T> items) { }
}

public class SomeCommand : ICommand
{
    // an implementation-specific member, NOT a member
    // of ICommand
    public int SomeControlCount { get; set; }
}

// a method that references implementation-speciic
// details. where should this go?
public void DoSomething ()
{
    SomeCommand command;
    int count = command.SomeControlCount;
}