вторник, 25 января 2011 г.

Явное и неявное преобразование в строку

Тут что-то подумалось. Почему люди так любят вызывать метод ToString() в случаях подобном этому:
int x = 10; 
string str = "Значение = " + x.ToString();
Лично я предпочитаю следующую запись:
string str = "Значение = " + x;
Это удобно для меня во многих случаях. Самый яркий пример: есть коллекция и я пытаюсь получить оттуда значение:
IList<string, int> list = new List<string, int>();
list.Add("key", 10);
string str = "Значение = " + list["key2"]; //Напишет "Значение = "
Если попробовать применить ф-ю list["key2"].ToString(), то получим исключение. Чтобы не было исключений, надо проверять возвращаемое значение из коллекции.
Лично мне кажется это неудобным и поэтому я использую комбинацию:
  • list["key2"] + ""
  • Последующая проверка на string.IsNullOrEmpty(), если нужно.
А вы что думаете?

2 комментария:

  1. Привет.

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

    В разных проектах часто пишутся разные хелперы типа ConvertUtils или ConverService или как то так, которые обладают нужной логикий преобразования одних типов в другие.

    Например, "классика" перегона query string в какие нить int/enums, с попутной проверкой на null или некорректный ввод.

    В итоге, рано или поздно, получается некий класс типа:

    public static class ConvertService{
    public static bool AsBool(object value);
    public static bool? AsNullableBool(object value);

    public static int? AsNullableInt(object value);
    public static float? AsNullableFloat(object value);

    public static string AsString(object value);
    }

    При этом, к примеру с bool еще тоже не понятно.
    Есть объект - это true или false?
    В числами - только на nullable? пр неуспехе.
    Со строками - тоже зависит, null или String.Empty?

    Логика вроде и "плавает" от проекта к проекту, но вроде и фиксируется.

    В любом случае,
    1) писать везде string.IsNullOrEmpty() тяжко и мусорит код
    2) писать везде .ToString() тоже
    3) обрабатывать ошибки парсинга-преобразования хочется централизованно
    4) int.TryParse и т.д. - жесть, мусрный код
    5) еще куча хотелок-проблем

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

    Нужна гибкость - делай интерфейсом, меняйте реализацию или же делайте перегрузки с какими нить лямдами к примеру :)

    Вот так, надеюсь хоть что то прояснилось и принесло пользу.

    ОтветитьУдалить
  2. Ну это как бы ДА. Согласен, проверка на string.IsNullOrEmpty() не всегда выгодной получается. Меня на самом деле волновал вопрос: зачем писать "Значение = " + x.ToString(), когда ясно видно, что в результате будет строка, да к тому же не всегда х != null. Чтобы избавиться от лишних проверок, на мой взгляд, лучше писать "Значение = " + x. Т.к. если не проверить на null значение х, то получим исключение. Вообще-то на этот вопрос меня натолкнули постоянные ошибки у начинающих разработчиков, которые еще и удивляются с чего это null reference exception появляются и главное откуда :)

    ОтветитьУдалить

Еще статьи

2leep.com