А отчего, кстати у Param MaxValue отсуствует MaxValue

😵‍💫

объекта ParamVolatile

речь об объекте Param

Ну так в Param есть MaxValue, играющее роль и Value. Если значение одно, то какая разница, как его назвать? А мне удобно назвать для совместимости с классом-наследником. Или назову его Value - тогда будет удобно в базовом классе, а в наследнике придётся приписать коммент, что Value играет роль максимального значения.

Если же я введу третью сущность (Value, MaxValue, CurrentValue), то это будет дублирование, т.к. Value и MaxValue играют одну роль и одинаково валидируются, и с ними одинаково обращаются клиенты классов Param и ParamVolatile. А вот клиентам будет путаница - все алгоритмы нужно перестроить, чтобы Value и MaxValue воспринимались одинаково. Проще в классах Param и ParamVolatile ввести одну условность и откомментить её, чем перелопачивать алгоритмы.

Да он описался. В хорошем смысле. )))

Переименуем MaxValue в Value в обоих классах. Лучше стало?

Нет конечно. Не следует торопиться. У нас пока еще нет реализации. Обсуждаются только проблемы "модели".

Похоже для Value нам еще нужен еще UpperLimit, так как LowerLimit всегда 0. /Специально выбрал какое то другое имя чтобы не путатся/

ну так уж в оригинале, сорри

ограничения для MaxValue у класса Param

Ну так в Param есть MaxValue, играющее роль и Value

как я понял для каждого значения нужно еще и ограничение или нет?

Не, не хотел вводить новые названия, вот же есть для всех параметров

public double CurrentValue { get; set; }
public double MaxValue { get; set; }

А вот клиентам будет путаница - все алгоритмы нужно перестроить,

то есть есть еще одно ограничение о котором умолчали?

Ну если идет речь о правке Big ball of mud, то и обсуждать особо нечего.

Похоже для Value нам еще нужен еще UpperLimit, так как LowerLimit всегда 0. /Специально выбрал какое то другое имя чтобы не путатся/

как я понял для каждого значения нужно еще и ограничение или нет?

Да. Любой Param или ParamVolatile имеет свой скажем так глобальный максимум и минимум, который они не могут превышать. И эти максимум и минимум я храню в валидирующем коде, а не в самих Param или ParamVolatile. А у ParamVolatile есть ещё текущий максимум, который он не может превышать, пока этот текущий максимум не изменится. У Param значение одно и оно редко меняется, поэтому оно валидируется "глобальными" максимумом и минимумом. У ParamVolatile же два значения - текущее, и текущий максимум - и они тоже валидируются через глобальные максимум и минимум, плюс текущее значение валидириуется через текущий максимум. Т.е.:

1. и у Param, и у ParamVolatile все значения валидируются через глобальные валидаторы
2. значение у Param и текущий максимум у ParamVolatile валидируются через глобальные валидаторы одинаково
3. клиентский код работает со значением Param и с текущим максимумом ParamVolatile одинаково, т.к. эти значению играют одинаковую роль (если бы ParamVolatile не изменялся в текущих пределах, то всегда был бы равен текущему максимуму - т.е. аналогично просто значению из Param).
4. текущее значение у ParamVolatile валидируется ещё и через текущий максимум

Это всё говорит о том, что при имплементации этих условий лучше бы для текущего максимума ParamVolatile унаследовать логику работы значения Param. И назвать их одинаково. А вот как конкретно - MaxValue или просто Value - другой вопрос, и больше к удобству или пониманию. Код работать будет с любым названием, если будут удовлетворяться все пункты выше.

По-моему, вы просто не можете себе представить, что за ParamVolatile такой может быть. А это просто - любое значение, которое расходуется и пополняется, и максимальная величина пополнения тоже может изменяться. И максимальная величина пополнения играет ту же роль, и так же обрабатывается многим клиентским кодом (например, он ожидает одинаковое имя свойства, а не делит их на два разных, не производит распознавание и ветвление), как и просто величина для значения, которое не расходуется и не пополняется, а просто есть. Я привёл пример скорости и запаса топлива. Скорость изменяется, но может быть и постоянной в течении какого-то времени, а топливо тратится непрерывно. Т.е. запас топлива более волатильная величина, чем скорость. Плюс топливо можно пополнить, но не более какой-то границы, а саму эту границу можно сдвинуть (у меня бак изменяемого объёма, или я канистры могу с собой взять и тасовать их - не важно).

Можно ещё сказать, что есть просто две величины - менее волатильная и более волатильная. И если менее волательную надо валидировать один раз при любом изменении, то более волатильную - дважды: текущее значение на две границы - волатильную и постоянную, и волатильную границу - на значение постоянной границы.

А вот клиентам будет путаница - все алгоритмы нужно перестроить,

то есть есть еще одно ограничение о котором умолчали?

Да, но оно простое - имена значения Param и текущего максимального значения ParamVolatile должны быть одинаковыми. Сделай это, и клиентский код будет нормально работать.

вы просто не можете себе представить, что за ParamVolatile такой может быть

https://ru.wikipedia.org/wiki/Вола�%...

и не только это

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

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

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

Когда же на это же самое смотрит кто то посторонний, то он обычно видит какую-то груду мусора.

Тоже самое было бы если бы и я какую то проблему рассказывал

Но уж если сильно хочется иметь "изменчивость", это скорее variability, changeability и море других. Хотя volatility тоже как бы в этом ряду, мне он воспринимается прежде всего как финансовый термин. Особенно на русском.

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

volatile в смысле "нестабильный, часто меняющийся" подобрано правильно.

и у Param, и у ParamVolatile все значения валидируются через глобальные валидаторы

кажется, что Штирлиц начал давал показания, но нет это только видимость

Видимо речь о подобной функции - double ValidateParam(value, min1, max1)

хотя на самом то деле она делает что то типа этого TransformValueToRange и min1, max1 определяются в конкретном классе Param

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

Это вообще абсолютно гениальное решение.

В одном случае мне выдают количество чего то, а другом максимум чего то

Есть подозрение, что с тоннами, килограммами и граммами - подобный бардак.

смысле "нестабильный, часто меняющийся" подобрано правильно

дело то не только в правильности. Хотя может это и мои личные тараканы. Подобное слово у меня ассоциируется с финансами и смотреть на него просто так, со стороны совершенно непривычно, в отличии от например unstable

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

Когда же на это же самое смотрит кто то посторонний, то он обычно видит какую-то груду мусора.

Тоже самое было бы если бы и я какую то проблему рассказывал

Но уж если сильно хочется иметь "изменчивость", это скорее variability, changeability и море других. Хотя volatility тоже как бы в этом ряду, мне он воспринимается прежде всего как финансовый термин. Особенно на русском.

Я хотел максимально абстрагироваться от конкретной реализации и темы. У меня в проекте эти классы с параметрами по-другому называются.

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

По-разному бывает. У меня у данных есть значения, с которыми одна часть кода работает (с максимальными), и есть часть кода, которая работает лишь с текущими значениями волатильных параметров. Например, та часть кода, что делает постоянный расчёт в цикле по нескольку десятков раз в секунду, работает с волатильными значениями, а то, что отрабатывает раз в несколько секунд или вообще по событиям - с максимальными значениями волатильных параметров или обычными значениями обычных параметров. Просто вы наверное не привыкли к таким областям программирования. В каком-то смысле это минус - узкий взгляд на вещи. )))

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

public class Parent
{
    double maxValue;
    public virtual double MaxValue
    {
        get => maxValue;
        set => maxValue = ValidateMaxValue(value);
    }
}

public class Child: Parent
{
    public override double MaxValue
    {
        get => base.MaxValue;
        set
        {
            base.MaxValue = value; // use validation from base class
            // some additional code - can be additional child class validation also, like this:
            // base.MaxValue = ValidateMaxValueInChild(value);
        }
    }
}

Просто вы наверное не привыкли к таким областям программирования.

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

что делает постоянный расчёт в цикле по нескольку десятков раз в секунду
что отрабатывает раз в несколько секунд или вообще по событиям

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

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