16 ms·

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

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 4y ago
>> 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.
- robalni 4y ago
  > 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.

Jtsummers 4y ago

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

robalni 4y ago
> 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.