Ask HN: Why do you make class members private?

Changing public things means changing the API. It means having to update documentation and, in case of breaking changes, major version bumps and maybe even other communication.

Changing private things and nobody might ever know.

It's about the need to coordinate and communicate changes and avoid people relying on unspecified behavior.

> You have been taught to do it so you just do it without thinking.

Ouch, that's a pretty careless reason to start with. Why does insulting your audience seem like the right first move?

In much of the classist (classy? You decide) code I've written, the entire reason that I've chosen to encapsulate the data into a class is that maintaining a consistent data structure requires book-keeping. The fields and methods associated with this bookkeeping are not part of the public interface, because there should never be a reason for consumers to handle that stuff directly.

In short: even in a project that "everybody has access to," you should still implement clean APIs. If you let everybody put hooks into everything anywhere, you get horrible hacky spaghetti code.

Edit: and just FYI, "private" does not mean "secure" or "secret" or "untouchable." A dedicated user can gain access to, and modify, everything.

Because people might throw a lot of weird things at my class and I want to make sure that no invalid values are set on those properties. I might use the property or class member later on. Let's assume my app uses stock prices and because of some issue, the price for a given equity comes through as Null. And then I don't want someone to be able to do Share.Price = API.Price.

I might want to have a method called SetPrice(APIPrice price) and there I do a check to see if it's a valid value as far as my code is concerned. I had a situation like this handling pricing information taken from a variety of indices but I want a calculation to still work out to something usable. Also, most business users don't understand what NULL * 3.5 would mean, but they would understand 0.0 * 3.5.

That's the main one off the top of my head.

Why do you write functions?

Should the implementation of a module not be able to utilize functions internally?

Re 1: The reason is not just to hide access, but also to permit change. Suppose someone implements a data structure using a backing array. Later on they change it to use a b-tree, but users have started directly accessing the backing array (because it's faster than the presented interface, even if just by a function call) and passing around references/pointers to array elements. Oops. You can't make changes anymore, the users are no longer using the intended data structure but a wrapped array.

Re 2: Supposing that the two collections have to be the same size, this implies that they get extended at the same time. If they are public, then anyone can add either a vertex or an edge at will. But they are not required (by the interface, only by a verbal contract of sorts) to extend both at the same time. With private members, you present a public interface that ensures both collections are updated simultaneously (or "simultaneously", as a transaction both happen before the method/function/subroutine/procedure/whatever the fuck ends). This makes the class/module author responsible for controlling this invariant, and not the users. Which is the only sane option unless you really like broken contracts and duplicated code scattered throughout a code base.