Timeline for Why have private fields, isn't protected enough?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 7, 2021 at 6:56 | comment | added | gnasher729 | If code is shared, and you feel it’s a good idea to change the base class I wrote (and sometimes it is), from that point in you have full responsibility for the class. | |
| Jun 11, 2016 at 12:14 | comment | added | Robbie Dee | Let us continue this discussion in chat. | |
| Jun 11, 2016 at 12:09 | comment | added | Arnab Datta | Please show me one language where using the private access modifier on a variable ensures that it can never be changed by anything other than the original class. I don't have any axe to grind about security. I'm pointing out that access modifiers are there to convey intent, not actual access. There's a huge difference. | |
| Jun 11, 2016 at 2:22 | comment | added | Arnab Datta | Nothing "hobby" about Java, and I said nothing about circumventing my own safeguards (why would I want to do that). You claim that any user (another coder who uses the implementation) could be certain that your hashmap implementation was behaving as intended. There is absolutely nothing to stop some random malicious coder from supplying a library that uses your implementation and puts some malicious code in it. The person who uses this library (containing your implementation) can not expect it to behave like you intended. They are at the mercy of the library, not you. | |
| Jun 10, 2016 at 18:25 | comment | added | Arnab Datta | Well, I thought it was pretty obvious but apparently not. "Private fields are typically about providing safeguards that the data is as the original coder expected. " <- not true, as I've quite plainly explained. | |
| Jun 10, 2016 at 18:21 | comment | added | Arnab Datta | I never said reflection was a great idea. I was merely stating the fact that it is there. Private variables in java are not private in the sense people think. It just has a label that says "please don't touch my stuff" on it. There are no safeguards just because someone slapped on a private keyword on to a variable. | |
| Jun 10, 2016 at 13:37 | comment | added | Arnab Datta | Reflection is part of the standard Java API. How is it anything other than "vanilla"? | |
| Jun 9, 2016 at 15:59 | comment | added | Arnab Datta | because getting fields using stuff like reflection is so hard. Sorry, but you can already ride a coach, horses and even a train through anything. tutorials.jenkov.com/java-reflection/… And I haven't even mentioned how private variables can be circumvented in python where the only thing stopping anyone from accessing anything is just writing two underscores in front of whatever they want to access. At the end of the day, "private" isn't really private. It's "public with a warning sign that this should not be used by the public". | |
| Mar 14, 2016 at 14:30 | comment | added | Nigel Touch | @Luaan +1 for when it's okay to touch others' privates! | |
| Mar 14, 2016 at 9:09 | comment | added | Luaan | @AdamLibuša I think your confusion mainly stems from the different OOP approaches different languages took. The root of OOP (as originally defined) is messaging - that means that everything is private, except for the messages you respond to. In most OOPish languages, this is exposed as "keep your data private" - a way to make the public interface as small as possible. The only way the user (be it a subclass or another class) has to manipulate your class is through the public interface you defined - similar to how you usually use the steering wheel and pedals to drive your car :) | |
| Mar 14, 2016 at 9:06 | comment | added | Luaan | @AdamLibuša "Don't share the code"? As soon as you publish any DLL at all, you're sharing the code - all the structures and methods and everything are there for the whole world to see, especially with languages that support reflection by default. Everyone can do whatever they want with "your code" - private is just a way of saying "don't touch these", and have it enforced within the compiler contract. In systems like .NET, this also has important security implications - you can only touch others' privates when you have full trust (basically the equivalent of admin/root access). | |
| Mar 12, 2016 at 10:05 | comment | added | Adam Libuša | If somebody needs to subclass your class, perhaps he should have access to your safeguards? And if you don't want somebody to change your safeguards to achieve some goal, perhaps don't share the code? It works like this in Ruby - private is more or less of a recommendation. | |
| Mar 11, 2016 at 19:38 | comment | added | anon | +1 for "ride a coach and horses through" anything. It's a great phrase that I wish I heard more. | |
| Mar 11, 2016 at 13:58 | comment | added | Broken_Window | +1 for a real case example | |
| Mar 11, 2016 at 9:44 | history | answered | Robbie Dee | CC BY-SA 3.0 |