1

I am learning OOP - I have read this answer a number of times and now slowly start to understand some of the practical uses of public interfaces (getters and setters). I understand there is no need to provide public accessors/mutators to every single object property as that breaks encapsulation.

However, in the answer, it is implied that any properties to be manipulated only within that object (i.e. those that don't have a public interface) don't require setters at all. Following this thought, that would imply the same about getters too.

When following S in SOLID, classes become quite small. As such I still use getters and setters for all my properties since adding validation to setters is easy. However, any property that shouldn't be accessed from outside the object I simply designate those setters / getters as protected.

This allows me to keep the validation for use within private methods while still restricting public access. I understand that getters and setters are used to stop other objects directly manipulating another objects properties, but as for 'private' setters / getters - is this necessary (validation aside) or even general practice?

The only other place I see reference to 'private' setters / getters is this answer which touches on inheritance and using private setters / getters to access the parent properties, which makes sense from an encapsulation perspective.

  • 1
    When you say "all" and in your case really mean it since you put it in bold text, there may be consequences. – JeffO Jul 15 '15 at 15:09
  • 1
    This is where your logic is flawed (and is not what that answer implies): Manipulated only within that object = don't have a public interface. If you want a public read only interface then you need to have a public get. – paparazzo Jul 15 '15 at 15:34
6

Consider these points:

  1. The "S" in solid does not mean "do one thing." It means "have one responsibility." If you find that your classes are proliferating, they may be too small. There's nothing wrong with a class doing many things, so long as those things all pertain to a single responsibility. Consider the case of a repository, which has several methods for accessing data, but only one responsibility (that of accessing data).

  2. You can validate information inside a class using ordinary methods. Getters and setters are intended to be consumed by a client. All other things being equal, you will confuse the fellow programmer who has to read your code after you write it, for no good reason.

3

Private getters and setters wouldn't even make that much sense, really. You would be encapsulating the encapsulation and bloat your class, making it hard to read.

The reason people create getters and setters is to restrict the client from doing something stupid with the class data, and for hiding what the class does to the data from the client.

  • Makes sense. However, if you want to do basic code validation within private methods, would private setters make sense? Or would a slightly different naming convention be used on those methods? setThing -> checkThing – myol Jul 15 '15 at 14:41
  • 2
    If you wanted to validate something, you would create a private method to do that, but it wouldn't be a "getter" or "setter" since the class already can set and get it. It would just be a private method called validate or something similar. – Lawrence Aiello Jul 15 '15 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.