Ask HN: Why do you make class members private?

1. So the reason here to use private is as a way to tell programmers to not use a thing in too many places because then it will be hard to change in all those places if you need to change the private member?

2. First, remember that I am only interested in code that everyone has write access to so even if something is private, everyone can still change it. "This makes the class/module author responsible for controlling this invariant" - does that mean that private is mostly useful together with a rule that only one person (or a few) should change code that belongs to their class, so that that person can keep the invariants in their head and that way avoid breaking them?

> To clarify, I'm only talking about code in the same project that everyone has access to. I'm not talking about defining an API for other people to use that don't have access to the code, like when you make a library.

A lot of people are ignoring this part of the question. The primary usefulness of object-oriented programming is scope control. Dependencies kill teams, and scope control helps them survive. The more I limit the scope of something, the easier for someone else to understand it and make necessary changes.

Imagine a language without scope control: When people try to understand how something works and what might break it, they have to consider all possible points of entry, which becomes every variable & function in your class.

Java programmers often pitch fits about "getters" and "setters", insisting that every variable be private and guarded by a public method. In your context, you might find this to be kind of silly since we're mostly just moving scope control around instead of limiting it, but good luck fighting that battle (I'm not going to try). At any rate, I still would not use this kind of annoyance as an excuse to wave off scope control as nothing but bureaucratic boilerplate. It has real value when used pragmatically.

> Dependencies kill teams

Do you mean that when you have structured the organization so that each class is worked on by at most one team, you want to reduce the number of dependencies between classes in order to reduce the number of dependencies between teams?

> they have to consider all possible points of entry

So is this basically what I mentioned, that you want to reduce the number of places you have to look in when you want to find all uses of it?

I too had that same question in the past, and the answers I got for variables were that by using them directly was harder if in the future you wanted to change the "how things are stored" in the class. With nowadays ides it's as easy as a refactor, so not a problem I personally ever had.

For personal projects I do use public things where necessary, and for team programming I also use public functions, but not public variables (sonar doesn't allow it) unless you make them final, which I do.

The important part is "when necessary". Think that each class is like a small little library (it should be at least). There are things you want others to know and use, and other internal things you don't. Public for the first, private for the second.

The reason is simple: to prevent objects from getting to an invalid state.

The set of property values of an object is its state, and you can model every possible valid state and state transition. Not every state is valid. If you allow all variables to be touched willy-nilly, you allow an object to be put into an invalid state.

The only variables and functions that should be public are those that cannot put an object into an invalid state.