>> 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 details were stable.
It doesn't matter how many teams are involved, you can (and ought) to use private even for yourself or for one team. It makes the system far more maintainable and reliable to either have an actual language notion of private or a community consensus on what is private (like _ prefixed member variables in Python). It reduces coupling, which is one of the number one ways to cripple development as a system grows in size.