HN Explorer

Ask HN: Why do you make class members private?

22 points by robalni ↗ HN
I know this is something that a lot of people do without thinking about it. So let's think about it.

I want to know the main reasons for making variables and functions in a class private. How is it better? What can happen if you don't do it?

Here are a few possible reasons that I can think of that someone could have:

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

* It reduces the number of files you have to search in if you want to find all uses of a member.

* The member is hard to understand so you want to discourage people from using it.

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.

116 comments

[ 5.1 ms ] story [ 170 ms ] thread
oxff
"With a sufficient number of users of an API,

it does not matter what you promise in the contract:

all observable behaviors of your system

will be depended on by somebody."

ronsor
Corollary:

If your programming language supports reflection, people will depend on private properties and methods regardless of what you do.

LanceH
People who can't accomplish something with an API because things are kept private won't be users.
lamontcg
It is always better to get the authors of the API to provide a supported way of doing something, rather than trying to bypass the interface. That requires human skills rather than computer skills though.
PaulHoule
You can change something private w/o breaking the api.
[deleted]
(comment deleted)
mytailorisrich
Variables should not be accessed directly outside of the object (encapsulation principle) and thus should all be private as a general rule.

Then, you will probably divide up the code into a number of separate methods for better structured code. All the methods that are purely internal and not part of the public API should be private if only to enforce the public API, this is also the encapsulation principle.

actusual
Python would like a word...
jstx1
While we're on Python and private methods - what's with everyone just _underscoring every method and variable by default? Does anyone teach people to do this or have I just ran into a few people with this habit by chance?

I know what _underscoring does in Python and what PEP8 recommends but doing it all the time for everything is so ugly and unnecessary.

ajoseps
I think it's because of what underscoring does. It's the "fake" privacy in Python. Also autocompleters tend to ignore those functions
swinglock
Perhaps you worked with Java/C++ programmers using Python.
frenchy
Probably for the same reason that zero-based versioning (https://0ver.org/) is so popular. People want to avoid commitment.
mytailorisrich
The language is not relevant to the question.

Making variables and methods private means making them inaccessible outside the class and I gave the typical reasons/best practices for that.

Saphyel
> Making variables and methods private means making them inaccessible outside the class and I gave the typical reasons/best practices for that.

The point they are making is in python there's no private method, everything is public. There's only a convention of "avoid using anything starting with "_"

beardyw
To me the point is that public members define the API.
xdavidliu
https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...
robalni
That's what it's called when you do things like that but what's the reason?

From the linked page I read: "Encapsulation is used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods."

So there are two possible reasons here:

1. The access could "expose hidden implementation details". This is not really a reason because it's just saying that you hide something to prevent access in a way that can expose what you hid.

2. The access could "violate state invariance maintained by the methods". Let's say the class has two arrays, `vertices` and `edges`. The state invariance is that they need to have the same number of items (like you have in a polygon). Then why would you make them private? A possible reason could be that it's easy to forget to add an edge if you add a vertex. But why would that be easier to remember if you do it in a member function?

Jtsummers
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.

robalni
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?

Jtsummers
1. It's private, only internal routines can use it. You aren't telling anyone to avoid using it, you are constraining where it can be used. You can use it directly in every internal routine if you want, that's not a problem. But no one outside the class/module can directly access it so if you change it (in whatever fashion) then those outside users will not be impacted because they are only dependent on the public interface. Now if you change the public interface, then they are impacted but that's often rare after the initial development effort, in my experience.

2. Forget about people, it's about place. I don't care how many people alter a particular class or module. What I care about is how many places some information has to exist within the code and has to be maintained and synchronized as a result.

As a mostly-useless-after-CS101 example, consider a bounded stack. An implementation might have a number (perhaps variable) which describes its limit, an array backing it, and another number indicating where the current "top" of the stack is (in languages where arrays carry their size you don't necessarily need that limit number as a separate thing).

If you leave everything public then every user of this bounded stack could directly alter the backing array and change the "top" of the stack, artificially indicating that something had been popped off or incorrectly incrementing beyond the limit. The limit itself could be altered without actually changing the backing array. The backing array could be made smaller or larger without correspondingly changing the limit. All of that would make this data structure useless, because it would be in an arbitrary, likely invalid, state.

In order to preserve the invariants of the system (limit == array size, 0 <= top <= limit; as just two of them), you write routines internal to this module (class, whatever) that make sure that when one is changed the others are changed, or that changes are only valid (top can never be larger than limit or less than 0). If users are able to bypass these routines by directly accessing these three member fields of the data structure then to correctly use it they have to preserve all these invariants everywhere they use the data structure. The code is now scattered and contains many duplications. Again, this isn't about people, it's about places and the number of them.

If you want to change the internal structure of this bounded stack, you have to change every place that currently accesses the public fields. Or you can be a sane developer, use private fields and public routines that manipulate the state so that it's always in a valid state. Now when you change the internal structure you only have to change those public routines and the private fields, no other place has to be altered. Every use of this bounded stack will look exactly the same as before, just push and pop and some error handling for when the stack is full or empty.

robalni
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 mean that they will not be impacted? If I change the internal array and all the places where it's used, nobody might even notice it. Or is the assumption that one team can only change inside the class and other teams can only change outside of the class? Remember that we assume that everyone has access to the all the code.

2.

> it's about places and the number of them.

So again, is private a way to tell programmers to reduce the number of places they use the member in so that it will be easier to change it?

Jtsummers
>> 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<T> {
    ...
    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 cares? What matters is that users of this class cannot, in a separate module/class, directly access those three fields. You cannot, after marking these as private, do this inside some other class or module:

  void some_method() {
    BoundedStack<Messages> stack = new BoundedStack<Messages>(100);
    ...
    stack.top = 200; // invalid
    ...
  }
That's invalid code, and that's a good thing. top is only modifiable by the BoundedStack class's own methods, which ensures that the state is always valid (so long as the code itself is correct, this is a trivial example to test so that's easy to verify one way or the other).

Using private, here, is moving a convention (like _ in Python or just a verbal agreement or a note in the documentation) to a compiler checked thing. It makes it guaranteed that users cannot (modulo reflection facilities in some languages, but that's jumping through hoops, but that's their problem when it breaks, not mine) access these without going through your intended interfaces.

>> those outside users will not be impacted

> What do you mean that they will not be impacted? If I change the internal array and all the places where it's used, nobody might even notice it. Or is the assumption that one team can only change inside the class and other teams can only change outside of the class? Remember that we assume that everyone has access to the all the code.

What I mean is that in the above, you can change the manner in which BoundedStack (or whatever the module is) is implemented and the interface remains the same. Users still have access to peek, pop, push, and whatever other methods you provided. What they cannot do is assume (you know what assuming does, right?) that the underlying representation is stable and bypass your intended interfaces. BoundedStack could switch to using a LinkedList for all the user needs to care, but if they assume it's an array backing it and have access to that array they might write something like this (even assuming they do everything as safely as possible so that this is a valid piece of data they're accessing, but in an unintended way):

  void bad_user() {
    BoundedStack<int> stack = new BoundedStack<int>(100);
    ...
    int a_datum = stack.array[n]; // where `n`, to be generous, is a valid item at this point
    ...
  }
Now let's suppose you used public fields and that currently works. Later on you decide to switch to a linked list. Hypothetical rationale: Users often create large bounds for the stack for exceptional circumstances, but have small stacks 99% of the time; a linked list ends up using a lot less memory because it doesn't allocate a massive, and mostly unused, array; access is sufficiently infrequent that the allocations are a non-issue. For some reason you left the name array in place, so the user's code still works as is, or even if you did change it they changed the name (or maybe you did when you applied the name change to the whole codebase, oops). Except that array[n] is now a linear operation and not constant time. Suddenly there's a massive performance regression because the users:

1. Did something unexpected with the code (why the fuck are they using a stack if they want to access anything but the top?).

2. Assumed the internal implementation deta...

robalni
> 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.

vanjajaja1
Consider a class like a HashedLinkedList. This is a linked list which allows direct access to nodes using dictionary look up. It is generally implemented with a LinkedList and Dictionary internally. The expectation is that all elements in the dictionary are in the linked list. Any deviation from this implementation detail will cause invalid state.

Making the list or the dictionary public opens you up to situations where consumers of the code modify either datastore independently and corrupt the consistency of the class.

bradwood
Easy way to avoid this problem: don't use classes.
Jtsummers
This idea is not limited to OO systems and classes, "private" visibility is very useful in languages that make use of modules as well.
choward
Solve what problem? I'm no fan of classes but I don't know what problem you're talking about specifically.
robalni
I guess, the problem of deciding whether to use private or not.
ipaddr
Marking it private doesn't allow any subclasses to change the value directly and must use the get/set methods provided where you can enforce standards or format accordingly.
jacquesm
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 could completely re-do the guts. Better still: all your tests will still work, as will your class documentation.

CoolGuySteve
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 practice the discipline required to do so seems unachievable.

Instead of using private members, if I want an interface I explicitly make an abstract base class interface and inherit from it.

This has two advantages: (1) unit tests are simpler when I can poke/prod the concrete internals because they're public. (2) I can make an "include" directory with the interfaces in it when I want to distribute a shared library and those interfaces will be more concise and less likely to leak all sorts of implementation details in the headers.

300bps
Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs has failed? [...] mainly based around working mostly in C++

Speaking as a C# developer, I think the concept of classes as tiny programs with tiny APIs works very well.

CoolGuySteve
It's been a decade since I used C# but the corporate design pattern culture of that language back then turned me off of it forever.

Everything looked like this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Maybe it's better now but the Java/C# practice of shoveling largely empty classes around with an IDE isn't something I'd point to as a good example.

Jtsummers
I've worked with C# off and on for over a decade, and never encountered anything close to that. Maybe the trick was that I was working with competent people.

Now the Fortran code I've encountered, that's the stuff of nightmares (to be fair to Fortran I've also encountered good code, but there seems to be a generation of embedded developers who have no formal programming training that all adopted a style of Fortran inspired by Cthulhu).

schmookeeg
Wow, what a repo. I can't even tell if the author is serious or this is some tinderbox-dry satire, bravo either way.

I'm sad that I've worked with plenty of codebases that look exactly like that and I twitched a little bit browsing around. :)

jacquesm
You can see the exact equivalent in the Java world.
bathtub365
From the readme: > Although this project is intended as satire, we take openness and inclusivity very seriously. To that end we have adopted the following code of conduct.
300bps
It's been a decade since I used C#

Well the last time I regularly used C++ was Borland C++ 3.1 from 1992. I'm not sure you'd be interested in my opinions on the language from 30 years ago.

jacquesm
No.

I think that compared to the giant hairballs of absolutely unmanageable spaghetti classes when done right have made larger scale projects tractable to mere mortals and have significantly improved software maintenance.

Classes done wrong (hundreds or even thousands of classes that all do almost nothing) are a terrible anti-pattern and should be avoided.

The exact same thing goes for services. And in fact for any tool used in a really bad way.

polotics
Sad to see this earnest post down-voted. Maybe you had to be more precise about the poor thought out nature of what you saw. In my experience you are right, in as much as developers whose notions of design only go so far as creating many small classes do not think enough about design...
kaba0
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.

lamontcg
> 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.

tejohnso
> you could completely re-do the guts...all your tests will still work

That's optimistic. I suspect there are some people who would be confused by your statement if they've been exposed mostly to tests that verify the steps taken by the implementation.

jacquesm
That's what I would call 'brittle tests'.
tejohnso
Yeah, "brittle", or "fragile", or "tightly coupled to the implementation"

In any case, it's not good. Also not uncommon.

jacquesm
> Also not uncommon.

Fair enough.

Typically this is a case of people not really getting what unit tests are for, so they end up testing the implementation rather than the behavior.

robalni
> 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?

jacquesm
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 contract, the contract is on the interface not on the guts.

It won't be 'hard to change' it may be impossible to change. Because someone that relies on your class may not have access to the code of the other class!

robalni
> 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.

CSDude
I don’t want them to show up in auto complete and accidentally use them because its not my business, I should not use things that I shouldnt.
ironmagma
We do it because that's how it's always been done. There is no why of OOP, there is only do.
Jtsummers
> There is no why of OOP, there is only do.

You really think that in the 50+ years of OOP and modular programming no one has considered why? That they've really just thrown shit at the wall and seen what stuck and never considered what to throw at the wall or why it stuck?

ironmagma
I’m sure lots of people have considered it. But lots of people can be wrong, myself included.

We do it because it’s largely automated by IDEs now. I strongly suspect that if IDEs didn’t make it so easy to do, we basically wouldn’t bother with it. Python does OOP just fine without real visibility control.

pessimizer
Because they are for the use of the functions within the class/module/whatever, not for the use of functions interfacing with it. Private functions for me are mainly for DRY, not for being secret special menu items.
chomp
Because classes are encapsulated data plus contracts over managing the object's state. If a class does not have control of its own data, then it cannot fulfill its contracts.

Let's say I have a Motorcycle class with 2 Wheel members. What if in the code I assume 2 Wheels when writing the serializer? And then someone comes along, instantiates a Motorcycle and nukes a Wheel? The code will break.

You can make an argument that OOP is not what you want, and instead create something akin to namespaces+data, and that's fine. But OOP's thing is to create a public API, and controlled state behind it.

Jtsummers
Suppose all fields are public, but the legal value of a field is dependent upon others. Then every time you change it you also have to include all the invariant preserving logic. This is duplication of the insane sort, totally unnecessary and gratuitous and gloriously error prone (at scale). The sane option is to make it private and have one place that checks that the input is valid and have everything make use of that.
gpderetta
Enforce invariants

I used to believe in information hiding, but not anymore.

kqr
> 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.

Within reason, you should treat every class as a tiny library that defines an API for other people to use.

That allows you freedom to change things within the class without breaking other code. It also makes it easier to prevent accidental misuse of the class that can leave it in weird states that aren't supposed to happen. It allows you to reason about the intended use cases of the class and write tests for them all.

ajoseps
To enforce a public API. I separate it so that callers don't accidentally muck up the workings of the class, and it simplifies how a class can be accessed and mutated
zwieback
Not for safety, gave up on that about 20 years ago. But definitely to keep state that I don't want to get messed up by outside calls. Also just to document/signal how an interface should get used to the outside world.
happytoexplain
>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

Even within a single module of code, your public interfaces are "APIs". If I write a class that displays a paged interface in a popup modal, there is no relevant difference between a member of my team utilizing that class (from within the same module) and other people using it (as a library I have published). They both read the documenting comments and access the public members to achieve their goals, and both will suffer from the same confusion if there is no way to tell which members are the interface and which members are implementation details.

robalni
> there is no relevant difference between a member of my team utilizing that class (from within the same module) and other people using it (as a library I have published).

The difference between a team member and a library user is that the team member works in the same project while library users have their own projects. So if you change something inside the class, you can change all the uses of that class in your project but you can't change other people's projects. That's why I added the clarification, because there is a very obvious reason to be strict about the API of a library that other people use: you can't change those uses.

alkonaut
If the exposed data is (and will always be) the same as the stored data, and the data is immutable - then you are right there is little point.

If the field is mutable then obviously you may want to keep it private to ensure some invariant, or to cache/invalidate/log something when accessed. Accessing the private data directly will circumvent that.

If the exposed data isn’t the same as the stored data (e.g a DateTime struct might have a field with a 32 bit Unix timestamp but only exposes year/month/day/hour…). The reason for not exposing it because you don’t want consumers to depend on it. If you changed to a 64 bit internal representation you will break any consumer who is using the private field. But if you only expose year/month/day/hour/… then you can solve your year-2038-problem by simply changing the data type. Anything exposed is depended on. Always. And here is the kicker: it doesn’t matter if your consumers are other classes in the same program, or library users for a shipped api, they are users and they will (mis)use your class in any way possible. In the library api case you break others’ code. In the internal code case you might get a missed cache, or a harder refactor or similar.

cowbolt
>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.

If you can see the use in access modifiers for libraries then it's not so hard to make the leap to its general usefulness. Defining objects with clear and simple APIs is extremely valuable when working on complex software projects. As the code base inevitably grows to a point where no one knows every part of it, you want developers to be able to contribute without having intimate knowledge of everything. The value proposition is the same as for third-party libraries.

nitwit005
Because if someone is reading or modifying a value where that never makes sense, it indicates a bug. Compilers and IDEs catching bugs automatically is always the ideal.
cwoolfe
I think that lurking behind the question is an assumption that freedom and openness is better. Freedom and openness is fine until you want to build a house. Then you actually have to put walls somewhere to hold the roof up...and then you build inner walls to hide the bathroom from the rest of the house. In building software, structure is inevitable. The rightly chosen structure will give benefits; poorly chosen structure will work against you. When I build a class, it serves a purpose to some other part of the system. The purpose it serves is understood by its public members and functions. Everything else is private. What happens if you don't do this is that the next person to read and use/modify this class isn't going to know what your intention was or all the details of how it works, so it helps to give them the benefit of some hints of structure.

The only time I break this rule is for data-transport type classes. For example if I serialize some object into some class X before sending it to some API. Since all those objects do is hold data, I see no point in making the members private. Many people do, I suppose out of habit; or in anticipation that maybe one day those objects will do more than hold data. I'd like to hear a good argument for making members private in data-transport type classes.

3np
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.

ungawatkt
Like alot of written code that doesn't really matter to the computer, I do it as a signal to the reader: you _shouldn't_ be messing with these variable/methods just to use the class. As often noted, someone can and will still go mess with them if they want to, but at least now it's obvious.