Здравствуйте, -VaS-, Вы писали:
VS>Понятно. Для библиотек согласен. Но делать всегда свойства вместо полей — паранойя. Смешно видеть у того же Фаулера в книжке по DSL вот такое:
VS>
VS>class Activity...
VS> public string Type { get; set; }
VS> public int Amount { get; set; }
VS> public int Revenue { get; set; }
VS> public string Location { get; set; }
VS>
VS>Это чисто data-класс. Никакого поведения там никогда не будет.
Так собственно какие преимущества имеет поле перед данной записью, кроме кол-ва символов?
VS>>>Свойства не являются механизмом инкапсуляции. Так же, как и методы, возвращающие состояние объекта. HL>>В чем принципиальное отличие свойства от пары методов Get/Set, кроме синтаксического сахара?
VS>Ни в чем, о том и речь. Я лишь хотел сказать, что обернув приватное поле свойством или парой методов get/set, вы нарушаете инкапсуляцию — внутреннее состояние выставлено наружу, и от того, что это красивое свойство, а не ужасное паблик-поле, ситуация не меняется.
Выше приводили аргументы, чем паблик свойства лучше паблик полей. В пользу полей что-то есть?
Директор:
MC> — Паша, что за фигня, почему я 20 минут готовил документы, потом нажал на Help и приложение закрылось?
MC> — Все нормально, Саш, все по гайдлайнам, там один компонентик выкинул недокументированное (неожиданное) исключение при открытии хелпа, а мы такие исключения ловить не должны — закрываемся, все по правилам!
MC> — ... (Директор посылает меня с такими правилами кое куда)
Лучше представьте куда пошлет Вас директор, когда приложение, беззвучно проглотив очередное исключение, потрет все документы на его машине, а заодно и базы с фин. отчетами. Неожиданное исключение — это однозначная смерть приложения, причем чем скорее — тем меньше вреда. Это не отменяет логгирование и какие-то меры (если возможно) по мягкому восстановлению (как в офисах, к примеру).
Как известно, 90% людей верят утверждениям, начинающимся со слов «как известно».
Здравствуйте, -VaS-, Вы писали:
VS>Это чисто data-класс. Никакого поведения там никогда не будет.
Жили-были POCO. С public-полями. Были они "чисто data-классами".
А потом из них решили сделать self-tracking entities... и настал апокалипсис.
VS>Ни в чем, о том и речь. Я лишь хотел сказать, что обернув приватное поле свойством или парой методов get/set, вы нарушаете инкапсуляцию
ORLY?
Выставляя наружу свойство, я скрываю реализацию механизма получения/установки значения этого свойства.
Если я завтра вместо тривиального
get { return this.myProperty; }
set { this.myProperty = value; }
захочу реализовать какой-нить INotifyPropertyChanged, я его спокойно реализую и никто не помрет.
Либо изменю логику так, что свойство не будет отображаться на приватное поле 1-1.
В случае с public-полем — придется переделать контракт.
Ума не приложу, откуда такая категоричность — "никогда не будет"? Вы Б-г? Ну или хотя бы Нострадамус?
Мне она показалась несколько устаревшей. Видимо, слишком долго он ее писал. Выразительность internal DSLs у него ограничивается возможностями Java, C# и Ruby (хотя последний в принципе ничего). Хотя есть целая книжка показывающая, чего можно достичь в рамках существующего языка (Boo). С другой стороны, автору удалось зацепить меня разработкой external DSL (ANTLR) Но последний у него рассмотрен скупо и местами с применением не best practics (обход AST в коде вместо создания tree grammar). В общем, если DSL для вас совершенно новая область, то прочитать стоит хотя бы потому, что это Фаулер Исли нет, то что-то новое вы там, скорее всего, не найдете. Ощущения основопологающего труда книга явно не производит.
S>Так собственно какие преимущества имеет поле перед данной записью, кроме кол-ва символов?
Поля проще. Если я вижу конструкцию, более сложную, чем она могла бы быть, у меня сразу возникает вопрос — зачем? Какие скрытые проблемы решаются? Любое усложнение кода должно быть чем-то продиктовано.
VS>>Ни в чем, о том и речь. Я лишь хотел сказать, что обернув приватное поле свойством или парой методов get/set, вы нарушаете инкапсуляцию — внутреннее состояние выставлено наружу, и от того, что это красивое свойство, а не ужасное паблик-поле, ситуация не меняется. S>Выше приводили аргументы, чем паблик свойства лучше паблик полей. В пользу полей что-то есть?
HL>Ума не приложу, откуда такая категоричность — "никогда не будет"? Вы Б-г? Ну или хотя бы Нострадамус?
Если рассужать как вы, то все private члены не sealed класса надо делать protected — а вдруг захочется вызвать из наследника (я такое видел)? И virtual — а вдруг захочется переопределить? Не надо писать код, который не нужен прямо сейчас или 210% будет нужен завтра (но не послезавтра). Это не касается публичных (для команды) контрактов.
Здравствуйте, -VaS-, Вы писали:
S>>Так собственно какие преимущества имеет поле перед данной записью, кроме кол-ва символов?
VS>Поля проще.
Чем поля проще?
VS>Если я вижу конструкцию, более сложную, чем она могла бы быть, у меня сразу возникает вопрос — зачем? Какие скрытые проблемы решаются? Любое усложнение кода должно быть чем-то продиктовано.
Преимущества свойств описаны выше. А тема простоты полей по отношению к свойствам пока не раскрыта...
Здравствуйте, -VaS-, Вы писали:
VS>Если рассужать как вы, то все private члены не sealed класса надо делать protected — а вдруг захочется вызвать из наследника (я такое видел)? И virtual — а вдруг захочется переопределить? Не надо писать код, который не нужен прямо сейчас или 210% будет нужен завтра (но не послезавтра). Это не касается публичных (для команды) контрактов.
Нет. protected-контракт — это тоже контракт, и его надо проектировать не менее тщательно, чем публичный. Вообще суть спора мне непонятна. Кстати, обратите внимание, что генераторы клиентских частей для WCF и веб-сервисов почему-то генерят свойства, а не поля. К чему бы это, не знаете?
Здравствуйте, Sinix, Вы писали:
S>rsdn такой rsdn... Пока не напишешь дисклаймер на 5 страниц "не рассматриваем очень частные случаи, включаем свои мозги" — не отстанут
А чего ты удивляешься? Тут же технари все с техническим образованием. А чему нас (и, надеюсь, вас тоже) учили? "Нельзя" == "НЕЛЬЗЯ", а не "Нельзя" == "Нельзя, но ...(тут куча оговорок)". Правила математической логики, панимаешь В ней не бывает ответов вроде "да нет наверное"
K>"Нельзя" == "НЕЛЬЗЯ", а не "Нельзя" == "Нельзя, но ...(тут куча оговорок)".
Мы же не в этюдах, нет?
Для инженерных тем "делать надо так" == "Если не понимаешь последствий, по-другому лучше не делать. Чтобы толково объяснить — почему, придётся пройти ускоренный курс хождения по граблям с глубоким погружением в матчасть. Поскольку ты не сделал этого сам, тебе оно не надо. Так что делать надо так."
Здравствуйте, Angler, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>Т.е. я согласен, что catch(Exception) быть не должно в идеале.
A>А чем плох catch(Exception) c re-throw в дебрях и логированием/сообщением об ошибке на самом верхнем уровне?
Что за дебри?
Да что ты цепляешься за этот log? Пусть будет так:
catch(Exception e)
{
//уберём за собой
resultList.ForEach(item => item.Dispose());
//какая нам нафиг разница, что там случилось при заполнении?
//пусть клиент разбирается);throw;
}
, то оно называется log & throw.
A>Да что ты цепляешься за этот log? Пусть будет так:
A>
A>catch(Exception e)
A> {
A> //уберём за собой
A> resultList.ForEach(item => item.Dispose());
A> //какая нам нафиг разница, что там случилось при заполнении?
A> //пусть клиент разбирается);
A> throw;
A> }
A>
A>Чем это плохо?
А тут все неплохо, если не будет исключений в item.Dispose()
Здравствуйте, Angler, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>А тут все неплохо
A>А это как понимать? A>
A>Т.е. я согласен, что catch(Exception) быть не должно в идеале.
A> "неплохо" и "идеал" две большие разницы, не находишь? Так чем же таки catch(Exception)+rethrow хуже?
Я разве утверждал что catch + rethrow хуже? В чем суть претензий ко мне?
Здравствуйте, samius, Вы писали:
A>> "неплохо" и "идеал" две большие разницы, не находишь? Так чем же таки catch(Exception)+rethrow хуже? S>Я разве утверждал что catch + rethrow хуже? В чем суть претензий ко мне?
Какие претензии? Спокойствие Мне было интересно обоснование твоей же фразы — "catch(Exception) быть не должно в идеале"
Здравствуйте, Angler, Вы писали:
A>Здравствуйте, samius, Вы писали:
A>>> "неплохо" и "идеал" две большие разницы, не находишь? Так чем же таки catch(Exception)+rethrow хуже? S>>Я разве утверждал что catch + rethrow хуже? В чем суть претензий ко мне?
A>Какие претензии? Спокойствие Мне было интересно обоснование твоей же фразы — "catch(Exception) быть не должно в идеале"
Боюсь, что ты пропустил контекст обсуждения. Я имел в виду catch(Exception) без проброса, как это в коде ТС.
Но последний у него рассмотрен скупо и местами с применением не best practics (обход AST в коде вместо создания tree grammar). В общем, если DSL для вас совершенно новая область, то прочитать стоит хотя бы потому, что это Фаулер 
