Есть ли польза от использования символа вместо строки для односимвольных значений?

Question

Для полей и свойств .NET, которые по определению содержат только один символ, есть ли какое-либо преимущество в определении их как char вместо строки? Или это неправильное использование типа данных char?

Я думаю о поле, которое может содержать M или F для пола, или среднюю букву, или индикатор, сохраненный в базе данных как Y или N. Я обычно определяю их как строку, но мне интересно должен ли я вместо этого определять их как char.

Answer 1

Да, char - правильный тип данных для этого. Общее правило: всегда выбирайте самый узкий (самый ограничительный) тип данных, возможный в контексте . Это означает, что любые недопустимые (или выходящие за пределы) данные не будут приняты, если они будут случайно введены, поэтому ваша программа / база данных станет менее подверженной ошибкам.

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

int[] value = new int[1] { 123 };
value[0] = 456;

до:

int value = 123;
value = 456;

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

Кроме того, когда дело доходит до манипулирования значениями в коде, вы должны обнаружить, что наличие поля в более подходящем типе данных (т. Е. char) делает его несколько более простым для правильного использования в коде.

С точки зрения производительности, я бы не подумал, что использование string даст вам значительные накладные расходы. Итак, это занимает незначительно больше памяти, но это, вероятно, не проблема. Однако я думаю, что другие причины, которые я только что предложил, объясняют, почему вы должны выбрать char.

Answer 2

A Char и 1 символ String не будут сильно отличаться в плане производительности. CLR проработает для вас строки, так что об этом стоит подумать (но, опять же, я не могу представить, что выигрыш в производительности будет значительным).

Помните, что язык программирования является полезным инструментом как астракция . Всегда создавайте полезные абстракции. Другими словами, я бы определил ваши поля следующим образом:

enum Gender { Male, Female }

class Foo
{
    Gender gender;
    Char middleInitial;
    Boolean indicator;
}

Этот класс является семантически ценным сейчас, потому что типы данных указывают на его использование. Всегда используйте правильный инструмент для работы.

Answer 3

Строки - это массивы символов, поэтому, если вы не уверены, что вам могут понадобиться свойства / методы, которые поставляются вместе с массивом (например, длина и функции подстроки), я бы сказал, придерживайтесь символа, так как вы уверены, что это только один символ.

Answer 4

Строковый класс будет иметь некоторые накладные расходы. Если у вас есть char, вам нужно будет представлять пустой с 0x00 или <space> или каким-то другим неизвестным индикатором? Будет ли это поступать или поступать из базы данных, и какое соглашение вы собираетесь использовать там?

Для этого я обычно предпочитаю enume / bools / native семантику на уровне приложения, переводя с и на любое соглашение с базой данных, которое требуется. Ведь Person.Gender == Female и if (!Person.IsDeceased) {} намного более читабельны и понятны.