Live data from Hacker News

Ask HN: Why do you make class members private?

news.ycombinator.com

101–110 of 117 posts

Re: Ask HN: Why do you make class members private?

#101

To hide implementation details from class users. You ideally only want to have a documented interface and all implementation details should be opaque to class users. This can be quite tricky and usually classes will export some state, typically done through getters and setters. Then one day you decide you want to aggressively refactor that class. Now you can because the interface can stay the same even though you cou…

Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs and private implementations has failed? Admittedly, my opinion is mainly based around working mostly in C++, but every codebase I work in of significant age is a knitted castle of interlocking classes with poorly thought out accessors and private variables. While the vision of carefully encapsulating implementation details is nice, in…

No, it didn’t fail. People are just bad at architecturing their programs and/or there is not enough time for technical debt.

While not much difference in C++ specifically, but having a distinction between a class that encapsulates state and a record/struct that is nothing but plain old data is essential in my opinion. Both are useful for different problems.

Re: Ask HN: Why do you make class members private?

#103
post #72

Earlier quoted context omitted.

> To hide implementation details from class users. Yes, that's what private does. My question was more why you should do that. > the interface can stay the same even though you could completely re-do the guts. So is the reason to use private that it's a way to tell programmers to not use something in too many places because that will make it hard to change in all those places if you need to change the private member?

No, it says 'this is not meant for you to change from the outside'. It's an implementation detail, not part of the interface and any references to it are bound to break without notice, warning or acceptance of the consequences. Think of the interface to your class as a contract: this is how this class works, from now until eternity (or until the next breaking change ;) ). Relying on implementation details breaks that…

> any references to it are bound to break

Do you mean that if someone changes a class member, they would not change in all places that use that class member? Why not?

> someone that relies on your class may not have access to the code

As I wrote in the clarification, I'm only interested in cases where everyone has access to all the code.

Re: Ask HN: Why do you make class members private?

#104
post #90

Earlier quoted context omitted.

1. So it's not to make it easier to change things? Otherwise what's the difference, in difficulty to change things, between using a member in 20 places outside of the class and 20 places inside the class? It's the same amount of code to change if you change the member. > But no one outside the class/module can directly access it Everyone can access all the code. > those outside users will not be impacted What do you…

>> But no one outside the class/module can directly access it > Everyone can access all the code. I don't care what everyone can access (in terms of altering on a filesystem and code repository). It's about what the code can access. public class BoundedStack { ... private int limit; // initialized in constructor private T[] array; private int top = 0; } Yes. Everyone who can see this code can alter this code, who car…

> What matters is that users of this class cannot, in a separate module/class, directly access those three fields.

Yes that's what private does, it makes sure that you can't access something from any place in the code. The questions is why you should make this constraint.

> That's invalid code

Is private used to tell programmers that if you change this variable or call this function, the object can be in an invalid state?

> For some reason you left the name array in place

Is the reason here that private makes it easier to find all uses of something because it reduces the number of places you have to look in? Example, you change the meaning of a variable but forget to change the name so the compiler will not tell you about all the places to change. You can still change all the uses of that member in the class because those uses are easy to find and know about.

Re: Ask HN: Why do you make class members private?

#105
post #79

Earlier quoted context omitted.

> The only variables and functions that should be public are those that cannot put an object into an invalid state. That's an interesting one. So a reason to use private is to tell programmers that calling this function or changing this variable can leave the object in an invalid state? I guess invalid state then means that you can't call a public function on that object. It might not be clear what an invalid state i…

Invalid state means invalid state. Suppose (going with my bounded stack example from another reply to you) you initialize the stack with: a_bounded_stack = new BoundedStack(100); There are various actions applied, correctly, through the interface (push, pop, and peek). Somewhere, you decide to manually alter the size of the stack but not through its interface (resize) a_bounded_stack.limit = 50; But you forget (someo…

> But you forget (someone came by with cookies) to actually shrink the backing array and also to change "top".

Someone could come by with cookies while I'm writing a private function too. This is more of a reason for having a function for doing something. Is the reason to make those variables private then to tell the programmer that there is a function that changes them and that you have to look through all the functions of the class before you touch them to see if there is a function that does what you need?

Re: Ask HN: Why do you make class members private?

#106
post #79

Earlier quoted context omitted.

> The only variables and functions that should be public are those that cannot put an object into an invalid state. That's an interesting one. So a reason to use private is to tell programmers that calling this function or changing this variable can leave the object in an invalid state? I guess invalid state then means that you can't call a public function on that object. It might not be clear what an invalid state i…

If it's intended to be in that state, then it's valid. But following the example: if you made the player's health a public property, code could straight up just set it to a negative number. The game engine this is running in may not properly support a negative health value. If instead it was set using a public method, there can be added checks to lower bound health to zero. And depending on the architecture, all of t…

Ok, let's assume we only care about states that's always invalid, like negative health. So then my question is the same as for Jtsummers: is private a way to tell the programmer to look at all member functions to see if there is already a function that does what you need?

Re: Ask HN: Why do you make class members private?

#107
post #71
post #34

> 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 asso…

> Ouch, that's a pretty careless reason to start with I think it's fine. This is probably the reason that I used to have for using private until I started thinking about it. > there should never be a reason for consumers to handle that stuff directly Are we assuming here that the organization is structured so that only one team works on a class, so that that's the team that knows how the bookkeeping is done and no ot…

> > Ouch, that's a pretty careless reason to start with

> I think it's fine. This is probably the reason that I used to have for using private until I started thinking about it.

I mean I understand if no-one would claim to have that reason currently because people like to have more specific reasons for what they do but it's still a valid reason for using private so I didn't want to leave it out.

Re: Ask HN: Why do you make class members private?

#108

Earlier quoted context omitted.

Invalid state means invalid state. Suppose (going with my bounded stack example from another reply to you) you initialize the stack with: a_bounded_stack = new BoundedStack(100); There are various actions applied, correctly, through the interface (push, pop, and peek). Somewhere, you decide to manually alter the size of the stack but not through its interface (resize) a_bounded_stack.limit = 50; But you forget (someo…

> But you forget (someone came by with cookies) to actually shrink the backing array and also to change "top". Someone could come by with cookies while I'm writing a private function too. This is more of a reason for having a function for doing something. Is the reason to make those variables private then to tell the programmer that there is a function that changes them and that you have to look through all the funct…

[deleted]

Re: Ask HN: Why do you make class members private?

#109

Earlier quoted context omitted.

If it's intended to be in that state, then it's valid. But following the example: if you made the player's health a public property, code could straight up just set it to a negative number. The game engine this is running in may not properly support a negative health value. If instead it was set using a public method, there can be added checks to lower bound health to zero. And depending on the architecture, all of t…

Ok, let's assume we only care about states that's always invalid, like negative health. So then my question is the same as for Jtsummers: is private a way to tell the programmer to look at all member functions to see if there is already a function that does what you need?

From your other replay:

> Is the reason to make those variables private then to tell the programmer that there is a function that changes them and that you have to look through all the functions of the class before you touch them to see if there is a function that does what you need?

I'm not sure I understand the question.

A private property is a property that a class user should have no reason to want to directly write to. Or more accurately, it's a variable that directly writing to could invalidate the state of the object. They are intermediate values or implementation details that define the state of the object. Reading them should be fine, but allowing unrestricted writing is dangerous. If there is reason to directly change the value, there should be a public method that includes validation to prevent the user from invalidating the object.

On the other hand, private methods exist for code re-use convenience purposes. You could just as easily only have public methods and write all logic inside of them. But a lot of the time you have pieces of code that could be reused between methods, but on its own doesn't guarantee the object to be in a valid state at the beginning or end of the call. So, you make it private. It only exists as a means of avoiding code duplication and possibly improving readability.

Private methods may also have value in inheritance / abstract classes, but I'm focusing on invalid state.

Re: Ask HN: Why do you make class members private?

#110

To hide implementation details from class users. You ideally only want to have a documented interface and all implementation details should be opaque to class users. This can be quite tricky and usually classes will export some state, typically done through getters and setters. Then one day you decide you want to aggressively refactor that class. Now you can because the interface can stay the same even though you cou…

Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs and private implementations has failed? Admittedly, my opinion is mainly based around working mostly in C++, but every codebase I work in of significant age is a knitted castle of interlocking classes with poorly thought out accessors and private variables. While the vision of carefully encapsulating implementation details is nice, in…

> Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs and private implementations has failed?

I lived the past 10 years in a ruby codebase where since effectively everything was public, we didn't mark enough stuff private and you can always YOLO monkeypatch or call things with `send(:method)` there was zero effective encapsulation.

And that pretty much crippled the product because now everything could be a public API so you can't change some shitty little helper to clean the code up somewhere because someone might have written code against that, in their private codebase that you have no visibility at all into. Every change becomes a potentially breaking change, because you have no idea how someone else's codebase might or might have fucked you by digging into your codebase.

Rejecting encapsulation is literally the dumbest post-OO take, and I have the scars to prove it.

Good fences make good neighbors and all that.

Post reply on HN