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

Question

У меня есть класс, содержащий ряд свойств, что-то вроде:

public class Update 
{ 
    public int Quantity { get; set; } 
    public decimal Price { get; set; } 
    public string Name { get; set; } 
} 

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

Один из вариантов, который у меня есть, состоит в том, чтобы сделать все типы значений Nullable, и поэтому значение null будет представлять собой концепцию не заданной. Хотя это сработает, мне не очень нравится идея иметь некоторые свойства явно Nullable (типы значений) и некоторые значения NULL в силу того, что они являются ссылочным типом. Определение класса выглядело бы уродливым, и я не уверен, что нулевая проверка является семантически лучшим подходом.

Я мог бы создать класс, очень похожий на Nullable<T>, который не имеет ограничений на T с IsSet. Я предпочитаю эту возможность использовать Nullable, но мне все же хотелось бы посмотреть, есть ли у кого альтернативное представление, которое лучше, чем предлагаемые мной варианты.

Answer 1

Вы действительно должны придерживаться существующей идиомы здесь. Используйте встроенную нулеустойчивость.

Я вижу, что ваша проблема с неопределенностью отличается от значений и типов ссылок. Ваше обходное решение будет работать. Но это просто косметическое изменение, которое вас заводит. Я рекомендую вам изменить себя, а не менять код в этом случае. Постарайтесь приспособиться к существующим конвенциям.

Редактировать: Иногда вам нужно сделать необязательным значение в общем коде. В этом случае вам нужно использовать какой-то пользовательский тип параметра. По опыту могу сказать, что это довольно неприятно для использования. Это не мое решение.

Answer 2

Упоминания типов уже обнуляемые, эффективны - если вы используете int?, decimal? и string затем каждый из ваших свойств могут быть пустыми.

Проблема возникает, если вы когда-либо хотите установить значение string в нулевую ссылку - если значение null является действительным значением, которое равно.

Вы, конечно, мог написать Maybe<T> типа, но я не уверен, что я бы - я бы, наверное, просто использовать пустой ... кроме всего прочего, это будет более знакомым для другого чтения коды которые используются для идиом C#. Для всех «анти-нулевых» настроений вокруг (которые я do делятся во многих ситуациях) бывают случаи, когда это самый простой подход.

Answer 3

Я не очень нравится идея иметь некоторые свойства Nullable (в типах значений), а некоторые нет (ссылочные типы)

ссылочных типов, очевидно, обнуляемые.

string t = null; //is totally valid 

Answer 4

Я бы сказал, что Nullable - это именно то, что вы хотите использовать для этой цели. Вы можете обернуть элементы со свойствами (как вы уже это делали), чтобы класс показывал нормальные значения снаружи вместе с настройками «он установлен», чтобы проверить, если это необходимо. Но внутри я бы использовал Nullable.

Answer 5

Чтобы предложить вам что-то новое ... Если вы просто говорите об одном классе, например «Обновление» с ограниченным числом членов, я бы использовал только IsSet.

Но если у вас есть несколько подобных классов с таким поведением или с множеством свойств, я могу предложить вам использовать t4-шаблоны. Вы можете, например, получить свойства класса (нужного типа или атрибута), как описано in this article, и автоматически сгенерировать код на основе списка свойств (реализовать любой дизайн, который вы хотите автоматически)

Я мог бы описать его больше, если он есть интересно ...

Answer 6

решения здесь

• использование Nullable, где нуль не является допустимым вариантом
• использовать значение по умолчанию, где нуль является допустимым вариантом, но вы совершенно уверены, что данное значение выиграло t t
• используйте логический флаг для каждого свойства, где null - допустимое значение, и вы не можете назвать значение по умолчанию, которое не будет использоваться когда-либо.

Примеры: Количество должно быть обнуляемым, потому что если он установлен его значение не будет аннулирована либо

Имя должно быть по умолчанию в «», если имя может быть нулевым (отсутствие имени) и вы уверены, что имя никогда не будет «"

Флаг, скажем, nameSet следует использовать, если имя может иметь нулевое значение, и вы не можете думать о значении по умолчанию. Этот флаг будет ложным по умолчанию, и когда вы сначала установите значение Name, флаг также должен быть установлен в true.

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