переиспользование свойств базового класса

обычно это функции

Закрываю глаза на всё остальное

переиспользование свойств базового класса

обычно это функции
Закрываю глаза на всё остальное

совершенно непривычно

я не привык к подобным извращениям

Не, ну вы прямо какой-то программерский консерватор-пуританен. Неужели не хотелось иногда пошалить, нарушить табу, выйти за рамки дозволенного? Или боитесь, что Дядя Боб придёт и поставит в угол за непослушание? )))

А зачем вообще дали возможность переопределять кучу разных членов класса, если пуритане говорят, что можно только методы и только в одной позе? ))

а просто код, работающий лишь с теми или другими частями параметров

Ну а на это тем более наплевать. Дай мне значение и дай мне максимум - это то что будет интересовать.

А не то что если параметр тип1 - получаем значение, а если тип2 получаем максимум.

клиентский код работает со значением Param и с текущим максимумом ParamVolatile одинаково

Это вообще абсолютно гениальное решение.
В одном случае мне выдают количество чего то, а другом максимум чего то

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

Ну например, "бонусная карта члена клуба" - она увеличивает максимальную заправку (максимальное значение волатильного параметра) и даёт скидку (значение обычного параметра), но не увеличивает текущее значение топлива в баке (текущее значение волатильного параметра).

Или например объект "неисправность такая-то" - уменьшает скорость (значение обычного параметра) и максимальный заряд аккумулятора (максимальное значение волатильного параметра), но не влияет на текущий заряд аккумулятора. Примеры немного отфанарные, просто более реальные неохота придумывать.

А не то что если параметр тип1 - получаем значение, а если тип2 получаем максимум.

Вот чтобы этого не было, я и назвал свойства одинаковыми именами, но значения в них хранятся по сути: для обычных параметров просто значения, для волатильных - максимальные значения. У меня в проекте они названы не MaxValue, а просто Value. Но для задания вопроса я подумал, что MaxValue наверное понятнее будет, т.к. в варианте с просто Value у волатильного параметра тогда будут свойства Value и CurrentValue, что тоже может ввести в заблуждение.

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

Неужели не хотелось иногда пошалить

Как то уже неинтересно класть кнопку на стул папе или маме

А зачем вообще дали возможность

А какого мне могут продать хороший нож, если я с ним могу выйти на улицу и поискать развлечений?

для обычного параметра он увеличивает просто его значение, а для волатильного - его максимальное значение

Ну так поэтому и говорю - гениальное решение

а того, как код обрабатывает эти параметры

код должен обрабатывать параметры с какой то логикой и логика не должна быть размазана по хлебу как масло.

что тоже может ввести в заблуждение.

Похоже что какие то части кода обязательно должны вводить в заблуждение.

Или например объект

А каким образом появились еще какие то объекты, которые связаны с несколькими различными параметрами?

Нада.

Нада.

Спасибо за развернутый и очень понятный ответ

Мы же вроде не указываем как нужно делать, а всего лишь высказываем мнение. А мнение можно высказывать лишь на основе переданной информации.

Так я давно передал информацию, что надо сделать. Уже много раз так и сяк сформулировал. А вы спрашиваете постоянно - а зачем, а имеет ли это какое-то отображение на реальный мир, а что скажет Дядя Боб? )))

Так я давно передал информацию, что надо сделать

Это вам так кажется, полную модель так и не удается построить, всё время выплывает что то новое.

Сказали - хочу зеленый листик, а потихоньку выясняется для чего

А вы спрашиваете постоянно - а зачем

Без полной "картины мира" многое кажется совершенно непонятным.

Возможно, что зная все, можно будет сказать - да других вариантов не видать.

По крайней мере, продолжение было воспринято именно так, что хочется узнать альтернативу.

Вы умеете мыслить абстрактно, без "полной картины мира"? Я написал, чего хочу, и предложил свой вариант исполнения. А вы не пытаетесь улучшить его или предложить свой, а постоянно спрашиваете, зачем мне это надо и почему я не делаю так, как привыкли вы.

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

foreach(var mod in modifiers)
    foreach(var param in params) // params is a List<Param>, where Param and ParamVolatile objects are placed together
        if(mod.ParamType == param.ParamType)
            param.MaxValue += mod.Value;

Если бы param.MaxValue имело бы разное имя в классах Param и ParamVolatile (например Value и MaxValue соответственно), но одинаковое по смыслу, то мне бы пришлось усложнять код - вводить распознавание волатильного и неволатильного параметра, а присвоение значения модификатора делать всё равно одинаково, типа такого

if(param is Param) param.Value += mod.Value;
else if(param is ParamVolatile) param.MaxValue += mod.Value;

В этом нет смысла. Но это лишь одно место, где пришлось бы так усложнять. А таких мест много. Если работа с Value и MaxValue идёт одинаково, т.к. это одно значение по смыслу, то проблема не в имплементации, а лишь в названии свойства. Я могу заменить его в любой момент без изменения кода. Вы же не можете взять в голову задачу лишь из-за смущающего вас названия свойства, хотя уже 10 раз объяснено, что это такое и зачем так сделано. Я вам написал, что можно заменить название MaxValue на просто Value - это вам поможет? Вы ответили, что нет - ведь теперь непонятно, чем отличаются Value и CurrentValue в ParamVolatile. Ну придумайте вариант лучше для названия свойства, но код-то от этого не поменяется.

Ещё можно поиграться с названиями классов. Скажем, не ParamVolatile, а ParamConsumable, или ParamExpendable, или ParamReplenishable. Вам бы это больше помогло? Свойства-то так бы и остались Value и CurrentValue или MaxValue и CurrentValue.

Меня вообще больше интересовал дизайн двух классов. И я спросил, что-то подобное видели или использовали? Видите какие-то минусы или варианты улучшения?

А куда это применить и как назвать - дело десятое.

Можно ли сделать лучше для описанной задачи (напомню - выделено жирным)? Может что с интерфейсами намутить?

Ничего мутить не надо.

Надо просто вынести валидацию в отдельную функцию и каждый класс должен валидировать то, за что он отвечает.

public class Param
{
    double maxValue;
    public virtual double MaxValue
    {
        get { return maxValue; }
        set
        {
           maxVaslue = value;
           Validate ();            
        }
    }

    protected virtual Validate ()
    {
    }
}
public class ParamVolatile : Param
{
    double currentValue;
    public double CurrentValue
    {
        get { return currentValue; }
        set
        {
           currentValue = value;
           Validate ();
        }
    }
    
    protected override void Validate ()
    {
        base.Validate ();
     
        currentValue = Math.Clamp(value, 0, MaxValue);
    }
}

Вроде неплохо, единственное что, при изменении CurrentValue вы валидируете и MaxValue, что не требуется.