Comments 17
Я бы посоветовал убрать из кода private set;, это позволит избежать случайной ошибки сделать класс изменяемым.
Тогда не получиться инициализировать эти свойства из конструктора.
Вы правы. Пост писался еще до 6го шарпа
Свойства
P.S. Почему статья не оформлена как перевод?
readonly были еще до C# 6.P.S. Почему статья не оформлена как перевод?
С ридонли полями примерно так же как и с private set пропертями в плане читаемости. Т.е. для того чтобы понять является ли класс изменяемым нам все равно нужно смотреть внутрь этого класса, по сигнатуре это непонятно. Тут бы помогло ключевое слово immutable.
>P.S. Почему статья не оформлена как перевод?
Я думаю свои статьи не очень правильно оформлять переводом, хотя тут не уверен насчет правил хабра.
>P.S. Почему статья не оформлена как перевод?
Я думаю свои статьи не очень правильно оформлять переводом, хотя тут не уверен насчет правил хабра.
Прошу прощения, не обратил внимания, что изначальная статья тоже ваша. Тогда помечать как перевод не нужно.
UFO just landed and posted this here
Тут я с вами (увж автор) не соглашусь, readonly пресекают изменяемость на корню а вот private set просто не позволяют изменить содержимое снаружи класса. В плане читаемости, когда видишь такое дело тут же ждешь подвоха, а нет ли тут moving parts которые провоцируются внутренним поведением класса.
В первом варианте выполнение Search(queryObject); не зависит от if, во втором зависит :)
UFO just landed and posted this here
Ещё ограничений:
* сериализация (например, стандартный XmlSerializer требует публичных read-write свойств и конструкторы без параметров)
* ORM (например, EntityFramework плохо дружит с read-only коллекциями)
* сериализация (например, стандартный XmlSerializer требует публичных read-write свойств и конструкторы без параметров)
* ORM (например, EntityFramework плохо дружит с read-only коллекциями)
Sign up to leave a comment.
Functional C#: Immutability