Абсолютно согласен, могли бы, и реализовывались легко бы. Но в конкретно моем случае, это вещи которые нельзя выдавать пользователям. А если описывать во внутренних ресурсах, то не нашлось причин разделять класс и его ограничения.
Да и нагружать статью поставкой правил из конфигов, думаю лишнее — и так довольно тяжелая статья вышла
В том то и дело, что предметная область не ложится на обычную обьектно-ориентированную модель.
Если ввести типы (Voltage и Temperature), то не плохо было бы еще унаследовать от них датчики конкретных производителей (например «Huaweo» и «Deck», где перые имеют подстройку, а вторые нет — Adjustment==0), потом унаследовать от них линейки датчиков(«Common» и «Flex» где вторые могут не просто измерять, а вычислять средние показатели за настроенный интервал — Interval!=0) — получатся классы типа VoltageDeckFlex в котором можно прописать конкретные модели с их возможными параметрами. При этом выяснится что у всех датчиков Flex по стандарту одинаковые ограничения для температурных и для напряжения, а классов VoltageFlex и TemperatureFlex нет и прописывать придется во всех классах (VoltageDeckFlex, VoltageHuaweoFlex, TemperatureDeckFlex, TemperatureHuaweoFlex)
С описанием же через атрибуты такой проблемы не возникнет
public class Sensor
{
public virtual SensorType Type { get; set; }
public virtual CompanyType Company{ get; set; }
public virtual ModelType Model{ get; set; }
[Number("Company=Huaweo", "0")]
[Number("Company=Deck", "-10..10", Force = "0")]
public virtual decimal Adjustment{ get; set; }
[Number("", "0")]
[Number("Model=Flex", "0..100", Force = "0")]
public virtual decimal Interval{ get; set; }
[Number("Type=Temperature", "200..600")]
[Number("Type=Voltage", "-400..400")]
[Number("Type=Voltage;Company=Deck;Model=Flex", "-600..600")]
public virtual decimal Value { get; set; }
}
Вторая проблема — если пользователь заполнил настройку, а потом выяснил что модель у него другая — надо класс менять.
Хоть про decimal и написанно, что хорошо подходит для финансовых расчетов, для любых других подсчетов которые помещаются на дисплее датчика использовать необходимо только decimal. Пример:
for (int i = 0; i < 10000; i++)
{
sumDouble += 0.001;
sumDecimal += 0.001m;
}
Так вот в double сумма не будет равна 10, а decimal будет.
А вот что это за 0.001 может быть:
моментальное потребление в 1 литр, и мы считаем потребление за почти три часа(10000 сек) и 10 кубометров не получается
это может быть шаг в поле принимающем значение от 0 до 10 в пользовательском интерфейсе, и при каком-то из нажатий стрелочки вверх вместо числа с тремя знаками после запятой, мы получим кучу девяток в хвосте
Примеров можно придумать много. Но все что можно или нужно представлять в десятичных дробях необходимо считать в decimal.
Вот в том то и дело, что с точки зрения того, кто будет пользоваться такой моделью, все очень просто. Поправил атрибут или повесил новый — и оно само работает. А вот как именно это работает наружу не вылезает. Ну как минимум за пол года никого не волновало. А вот предметная логика (то как зависят свойства друг от друга) собраны в одном месте и читабельны.
От чего зависит свойство мы не сможем задать. Конкретно тут это “Type” — это свойство динамическое. Зависеть свойство может от любого другого поля в классе, а в другом классе вообще другие поля.А атрибут должен работать с разными классами. Это в JavaScript можно задавать то, что не объявлено. А тут вы не сможете в атрибуте прописать все поля от которых может зависить свойство. Вторая проблема, почему числа прописывается в строках — нельзя в атрибутах пользоваться decimal.
Да и нагружать статью поставкой правил из конфигов, думаю лишнее — и так довольно тяжелая статья вышла
Если ввести типы (Voltage и Temperature), то не плохо было бы еще унаследовать от них датчики конкретных производителей (например «Huaweo» и «Deck», где перые имеют подстройку, а вторые нет — Adjustment==0), потом унаследовать от них линейки датчиков(«Common» и «Flex» где вторые могут не просто измерять, а вычислять средние показатели за настроенный интервал — Interval!=0) — получатся классы типа VoltageDeckFlex в котором можно прописать конкретные модели с их возможными параметрами. При этом выяснится что у всех датчиков Flex по стандарту одинаковые ограничения для температурных и для напряжения, а классов VoltageFlex и TemperatureFlex нет и прописывать придется во всех классах (VoltageDeckFlex, VoltageHuaweoFlex, TemperatureDeckFlex, TemperatureHuaweoFlex)
С описанием же через атрибуты такой проблемы не возникнет
Вторая проблема — если пользователь заполнил настройку, а потом выяснил что модель у него другая — надо класс менять.
Так вот в double сумма не будет равна 10, а decimal будет.
А вот что это за 0.001 может быть:
Примеров можно придумать много. Но все что можно или нужно представлять в десятичных дробях необходимо считать в decimal.
Не получится прописать все свойства от которых можно строить зависимости, это необходимо прописывать гибко. Строки подходят для описания зависимостей
От чего зависит свойство мы не сможем задать. Конкретно тут это “Type” — это свойство динамическое. Зависеть свойство может от любого другого поля в классе, а в другом классе вообще другие поля.А атрибут должен работать с разными классами. Это в JavaScript можно задавать то, что не объявлено. А тут вы не сможете в атрибуте прописать все поля от которых может зависить свойство. Вторая проблема, почему числа прописывается в строках — нельзя в атрибутах пользоваться decimal.