Private setters are good, but they are still only a partial fix. c#6 introduced readonly auto-implemented properties - where the set is omitted the property is truly readonly - the c# compiler creates a readonly backing field for that property, so you can only set it's value inline or inside one of your type's constructors - while with a private setter you can still change the property's value from anywhere inside your type.
There are use-cases for both immutable and readonly properties, and even for public setters (though admittedly, I totally agree that these should be only used with caution and after careful consideration), though IMHO, A good design should strive for immutability in most cases.
Ahhh, I didn't realize c# 6 introduced read only for all properties. I've used read only collections pretty extensively but never for other types.
Yeah, in some cases there is a use case for non private setters. But I can think of almost zero situations where a private one wouldn't give more robust and easy to amend code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Private setters are good, but they are still only a partial fix. c#6 introduced readonly auto-implemented properties - where the
set
is omitted the property is truly readonly - the c# compiler creates a readonly backing field for that property, so you can only set it's value inline or inside one of your type's constructors - while with a private setter you can still change the property's value from anywhere inside your type.There are use-cases for both immutable and readonly properties, and even for public setters (though admittedly, I totally agree that these should be only used with caution and after careful consideration), though IMHO, A good design should strive for immutability in most cases.
Ahhh, I didn't realize c# 6 introduced read only for all properties. I've used read only collections pretty extensively but never for other types.
Yeah, in some cases there is a use case for non private setters. But I can think of almost zero situations where a private one wouldn't give more robust and easy to amend code.