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