Как я могу улучшить этот дизайн?

У меня была очень похожая проблема в прошлом, и в итоге я переместил логику для проверки параметров в соответствующий класс ActionParameters . Этот подход будет работать из коробки, если ваши классы параметров выровнены с классами BusinessAction.

Если это не так, это становится более болезненным. У вас есть следующие варианты (я бы предпочел первый лично):

1. Обернуть все параметры в IValidatableParameters . Реализации будут согласованы с бизнес-действиями и обеспечат валидацию
2. Просто подавите это предупреждение
3. Перенесите эту проверку в родительские классы, но тогда вы получите дублирование кода
4. Перенесите эту проверку в метод, который фактически использует параметры (но потом ваш код не работает)

Где предполагается использовать параметры: из CommonMethod? Непонятно, почему параметры должны быть действительными во время создания экземпляра, а не во время использования, и поэтому вы можете оставить это производному классу для проверки параметров перед использованием.

РЕДАКТИРОВАТЬ - Учитывая то, что я знаю, проблема, похоже, связана с особой работой, необходимой для создания класса. Для меня это говорит о классе Factory, используемом для создания экземпляров BaseBusinessAction, в котором он будет вызывать виртуальный Validate () в экземпляре, который он создает, когда он его создает.

Почему бы не сделать что-то вроде этого:

public abstract class BaseBusinessAction<TActionParameters> 
    : where TActionParameters : IActionParameters
{

    protected abstract TActionParameters Parameters { get; }

    protected abstract bool ParametersAreValid();

    public void CommonMethod() { ... }
}

Теперь конкретный класс должен позаботиться о параметрах и обеспечении их достоверности. Я бы просто принудил CommonMethod вызвать метод ParametersAreValid , прежде чем делать что-либо еще.

Как насчет переноса валидации в более распространенное место в логике. Вместо того чтобы запускать проверку в конструкторе, запускайте ее при первом (и только первом) вызове метода. Таким образом, другие разработчики смогут создавать объект, затем изменять или исправлять параметры перед выполнением действия.

Это можно сделать, изменив getter/setter для свойства Parameters, чтобы все, что использует параметры, проверяло их при первом использовании.

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

Я обычно помещаю такую ​​проверку в начало любого вызываемого метода. Например,

public MyAction(MyParameters actionParameters, bool something)
    : base(actionParameters) 
{ 
    #region Pre-Conditions
        if (actionParameters == null) throw new ArgumentNullException();
        // Perform additional validation here...
    #endregion Pre-Conditions

    this.something = something; 
} 

Надеюсь, это поможет.

Я бы рекомендовал применить к этой проблеме Принцип единственной ответственности . Кажется, что класс Action должен отвечать за одну вещь; выполнение действия. При этом валидацию нужно вынести в отдельный объект, который отвечает только за валидацию. Вы могли бы использовать какой-нибудь общий интерфейс, такой как этот, для определения валидатора:

IParameterValidator<TActionParameters>
{
    Validate(TActionParameters parameters);
}

Затем вы можете добавить это в свой базовый конструктор и вызвать там метод проверки:

protected BaseBusinessAction(IParameterValidator<TActionParameters> validator, TActionParameters actionParameters)
{
    if (actionParameters == null) 
        throw new ArgumentNullException("actionParameters"); 

    this.Parameters = actionParameters;

    if (!validator.Validate(actionParameters)) 
        throw new ArgumentException("Valid parameters must be supplied", "actionParameters");
}

У этого подхода есть приятное скрытое преимущество, а именно: это позволяет вам более легко повторно использовать правила проверки, общие для всех действий. Если вы используете контейнер IoC, вы также можете легко добавить соглашения о привязке для автоматической привязки реализаций IParameterValidator соответствующим образом в зависимости от типа TActionParameters