OM
на
public int Foo { get; set; }а в чем смысл кроме имплементации интерфейса? увеличения коллстека?
Size: a a a
2020 January 01
К
а в чем смысл кроме имплементации интерфейса? увеличения коллстека?
смысл в том что плохо оставлять поле публичным
просто плохая практика, как и глобальные переменные
просто плохая практика, как и глобальные переменные
OM
я и спрашиваю о том, в чем плохо конкретно, если поведение одинаково
К
я и спрашиваю о том, в чем плохо конкретно, если поведение одинаково
OM
допустим
и как часто у вас наступает это позже?
и как часто у вас наступает это позже?
OM
чисто субъективное ощущение интересно
IC
я и спрашиваю о том, в чем плохо конкретно, если поведение одинаково
Дело не в частоте, а в ненулевой вероятности и количестве проблем, которые появляются при наступлении этой вероятности.
RN
смысл в том что плохо оставлять поле публичным
просто плохая практика, как и глобальные переменные
просто плохая практика, как и глобальные переменные
Не сказал бы, что это плохая практика - скорее трейдофф. Например, навешивание дополнительной логики на get/set, как по мне - это спорная идея, которая уменьшает понятность кода и увеличивает вероятность случайной ошибки, трудной для отладки
RN
И необходимости переопределять get/set у меня не возникало уже несколько лет. И, пожалуй, если бы она сейчас возникла - я бы постарался найти способ обойтись без этого
К
допустим
и как часто у вас наступает это позже?
и как часто у вас наступает это позже?
достаточно часто хочется ограничивать запись, сделать private или protected или может даже internal, со свойством это сделается моментально
RN
достаточно часто хочется ограничивать запись, сделать private или protected или может даже internal, со свойством это сделается моментально
А это точно также реализуется через readonly или навешивание дефолтного get; set в тот момент, когда это понадобилось - вроде бы никаких дополнительных изменений в коде не потребуется
OM
Дело не в частоте, а в ненулевой вероятности и количестве проблем, которые появляются при наступлении этой вероятности.
это больше выглядит как что-то аналогичное преждевременной оптимизации
когда-то там что-то должно наступить и оно не наступает
потому что просто, если и наступает, то касается сразу переписывания крупного участка
когда-то там что-то должно наступить и оно не наступает
потому что просто, если и наступает, то касается сразу переписывания крупного участка
К
А это точно также реализуется через readonly или навешивание дефолтного get; set в тот момент, когда это понадобилось - вроде бы никаких дополнительных изменений в коде не потребуется
если ты пишешь либу, то тебя возненавидят разрабы за изменение поля на свойство
OM
достаточно часто хочется ограничивать запись, сделать private или protected или может даже internal, со свойством это сделается моментально
так ты обычно сразу и ограничиваешь, в этом кейсе понятно
RN
ну и readonly это не уровень доступа к переменной, это очень разное, ты не можешь ридонли переменную перезаписать позже
Тьфу, да, тут ошибся
RN
если ты пишешь либу, то тебя возненавидят разрабы за изменение поля на свойство
Но все еще, если ты пишешь либу, то тебя могут возненавидеть и за то, что ты сделал прежде публичное поле приватным :)
RN
Такие штуки в принципе грешноваты с точки зрения дизайна
К
Но все еще, если ты пишешь либу, то тебя могут возненавидеть и за то, что ты сделал прежде публичное поле приватным :)
изменение уровня доступа это очевидное изменение, компилятор покажет что не так.
а изменение поля на свойство никак не отразится, у разраба бомбанет, и это ок если он сразу сообразит что не так было при обновлении либы
а изменение поля на свойство никак не отразится, у разраба бомбанет, и это ок если он сразу сообразит что не так было при обновлении либы
OM
просто обычно заходишь в код и там тысячелетиями лежат эти гетсет
их либо сразу при проектировании размечают модификаторами доступа, либо они вот так всю свою жизнь и лежат
их либо сразу при проектировании размечают модификаторами доступа, либо они вот так всю свою жизнь и лежат