2

Even though I could write something like this (In C#. There are, of course, equivalents in other languages):

public int SomeNumber { private get; set; }

I have never encountered something like this. Is there any particular reason?

Edit: The question has been suggested as duplicated of Private setters and getters. The question there is about using properties as fields (private getters and setters):

However, any property that shouldn't be accessed from outside the object I simply designate those setters/getters as protected.

My question is not a duplicate since it is about properties with private getters and public setters.

Michael Haddad
  • 2,651
  • 3
  • 17
  • 27
  • 1
    Possible duplicate of [Private setters and getters](https://softwareengineering.stackexchange.com/questions/289826/private-setters-and-getters) – gnat Nov 21 '17 at 09:49
  • see also: [Are trivial protected getters blatant overkill?](https://softwareengineering.stackexchange.com/questions/215450/are-trivial-protected-getters-blatant-overkill) – gnat Nov 21 '17 at 09:50
  • @gnat, thanks - this is not a duplicate. I have edited the question to demonstrate why. Also, duplicate questions are not bad questions, they just suggest that the OP didn't find the original questions. There is no need to reduce the OP reputation. – Michael Haddad Nov 21 '17 at 10:04
  • *Is there any particular reason?* For what? Why you have never seen it or why it would be used? – Robbie Dee Nov 21 '17 at 11:40
  • @RobbieDee - I am asking if I didn't see this because I simply didn't see enough, or because there is a problem with such a design. – Michael Haddad Nov 21 '17 at 11:44
  • 1
    The usual reason is because it was public or protected, then someone made it private, and did not bother to make it a field since functionally it works the same as a field. – Frank Hileman Nov 21 '17 at 23:20

2 Answers2

8

I see such code often, and I do not like it.

My colleagues often use that for injecting some dependencies into an instance. But by doing so, they open up that property for change some when later on, while the property is expected to be set during object creation only.

And that's the reason why I do not like it: you cannot be sure that the public setter gets called later, and changes state of the instance which you thought was stable.

That is, when it is meant for dependency injection, use way of a proper dependency injection at object creation. If it is meant for changing the state of the instance, better use a method ("command") to infer that purpose.

Bernhard Hiller
  • 1,953
  • 1
  • 12
  • 17
  • This isn't an answer so much as a detailed comment. Could you edit your answer to more directly respond to the question, "Is there any reason to avoid private getters?" – Neil Nov 21 '17 at 11:38
  • 1
    That often happens if DI is retrofitted. Reworking constructors to handle one or more assets that are derived internally can be a considerable undertaking. I'm not passing comment on the rights and wrongs, just that it happens. – Robbie Dee Nov 21 '17 at 11:43
4

The reason you have never seen this before is not because such code would cause any immediate problems. The reason is probably: this combination is not particular useful.

Code which makes setters public allows calling code to change the object's state, then the calling code "knows" already the content of what was passed into through the setter, and there is simply no point in "hiding" this content from the outside by making the getter private. So there is not much benefit from that, quite the opposite, testing the object's state or reusing the object gets typically harder.

Compare this, for example, with the combination of a private setter together with a public getter. This often very useful for restricting or preventing unwanted side effects, and it is required when designing immutable objects.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • What about, for example, making a property setter public so it could be set by the designer, but the getter private, because it should not be used by other classes? – Michael Haddad Dec 15 '17 at 12:08
  • 1
    @Sipo: if by "designer" you mean a tool like "Visual Studio Designer" (and not a person): most of the designer tools in Visual Studio display the content of properties in some nice GUI, a developer can edit them with the GUI and write them back. So a designer tool will typically need read **and** write access. – Doc Brown Dec 15 '17 at 14:18