ID:181110
Aug 1 2011, 7:16 pm
|
|
I'm curious to know; why would you ever use protected or private in a program? Is it for security reasons? Is it because that's simply the way it's traditionally done? If you don't know what I'm talking about, take this Java code:
class Ball { public String name = "Billy"; private int ID = 12345; } class BallLoader { Ball loadBall; BallLoader() { loadBall = new Ball() System.out.println(loadBall.name); // this works System.out.println(loadBall.ID); // this will not work and give a compile error } }Why would you use private? It seems it'd be more trouble to define a getID() method that returns the private variable. It would save you a lot of trouble to just set everything to public. | |
It enforces separation of interface and implementation.
Programming is easier in the long run if things work like little magical black boxes - you call Add() on the list and it adds to the list, and Remove() removes from the list, and you don't need to do magic by messing with the internal data structures to fake an Add(). This kind of abstraction is useful in a million different ways - it means you need to know less about a thing to use it, which is handy when programs get too large to hold it all in your head. It means you can replace a thing or change how it works without affecting anything else too much, which is handy when it turns out to be too slow/buggy/tricky/whatever to do it the way it's being done. And it makes code easier to maintain, because stuff is only done in one place. | |
Try making changes to a class used extensively in a 250,000 line project, when the class only exposed public variables, instead of hiding them. It's a bitch.
The reason you don't see the benefit is the reason DM doesn't make any real effort to include access modifiers, for a single programmer project, it's "fine" if stuff is public. Lets assume you change the way IDs on ball objects are stored. Maybe they dynamically change over time, or you decide the ID should actually be derived from a database call instead. If the ID variable is public, you now need to replace it with a method call, like getID(). That call will then do your new logic. Because everyone was using that old public variable, you now need to change all the code that was referring to ID directly. Admittedly a small change, but it's a change all the same. If you'd made the variable private and provided an accessor method like getID(), you change the internals of your ball class to have the new logic, that's it. Anything using that class is fine, and will just work the same as before. You can actually completely gut entire classes that way and other people won't know. More importantly, they don't /need/ to know. The fine art of not caring, or being smart and lazy. | |
The instances are declared private so that they could only be accessed within the same class and not from a different module. This is used as such so that accidental referencing would not be allowed access and write permissions.
When you get access to a private variable or function, you should be within the bounds of the class you are on. And there should be a more complex way in which you can be allowed access to it just to be sure that you are doing the right thing. | |
<font face="Consolas">
<font color="green">// C++ code</font>
<font color="blue">class</font> foo {
<font color="blue">char</font> *data;
<font color="blue">public:</font>
<font color="blue">char</font>* GetData() {
<font color="blue">if</font>(!data)
LoadData();
<font color="blue">return</font> data;
}
};
</font>
For SetData(<font color="blue">char</font>*) you could check if it's actually valid before changing variable.