+ 7
uses of java private access-modifiers
people say that private accesss-modifiers increase your code security, but if you compile your code into a .class format. wouldn't people not be able to see your codes anyway? and why don't people use all public access-modifiers to make their life easier? pardon me if this is a stupid analogy, since i am still a newcomer in java.
11 Antworten
+ 17
The ability to make changes in your implementation code without breaking the code of others who use your code is a key benefit of encapsulation.
You want to hide implementation details behind a public programming 'interface'. By interface, we mean the set of accessible methods your code makes available for other code to call—in other words, your code's API.
By hiding implementation details, you can rework your method code (perhaps also altering the way variables are used by your class) without forcing a change in the code that calls your changed method.
+ 17
If you want maintainability, flexibility, and extensibility (and of course, you do), your design must include encapsulation.
How do you do that?
▪Keep instance variables protected (with an access modifier, often 'private').
▪Make 'public' accessor methods, and force calling code to use those methods rather than directly accessing the instance variable. These so-called accessor methods allow users of your class to 'set' a variable's value or 'get' a variable's value.
▪For these accessor methods, use the most common naming convention of
set<someProperty> and
get<someProperty>.
+ 6
You need to define public setters/getters that do essential checks from a security/safety point of view for your private members to be useful outside the class.
+ 6
Yes that's right, but if someone tried to set a string value to an integer variable, it wouldn't even get past the compilation stage.
+ 5
lvl 1 crook for example, within the public setAttribute method, you can do checks on the value e.g. if ((value>0) && (value<100)) and only set the private attributeName to value if this condition is satisfied. This is just a simple example but the additional checks prevent the attribute from being set to an illegal value.
+ 5
I must concur completely with the answers from MeanMachine as these are the most pragmatic responses which I can relate to in my own experience and usage in designing maintainable code on large application code bases.
+ 4
i think you are misunderstanding what security means in this context, what we mean ist that the programmer doesn‘t accidentaly put stuff where it shouldn‘t be. for example put a number greater than 10 in an attribute which should only contain numbers between 0 and 10
+ 3
it makes your life easier but if you are working with many programmers they don‘t know your code in detail they might accidentaly destroy invariants that you want in you classes when using them which would lead to errors. by setting stuff as private you are signaling to them that whatever is marked private is internal to the class and additionaly you are preventing that people accidentaly call methods that they shouldn‘t call
+ 3
yes Sonic i understand the concepts of encapsulation in using setters & getters. I am simply doubting on the way classes are set and getted.
let's say i use a public class-modifier.
if i want to set an attribute, i can simply do it by
object.attributeName = value
and using encapsulation it would turn into
object.setAttributeName(value)
isn't it still the same that the programmer still has the ability to change and look at the attribute values? i don't really see any difference in security by doing this. Is there really an improvement in security with encapsulation if everyone can just use the set & get method instead of explicitly changing the attribute values?
+ 3
Max & Sonic, i think i understand what you mean by that.
By security you could say a safer way of setting the attributes by validating it first.
Let us say that someone is trying to set an int attribute with a string data type.
the set method would validate the data type inputted first before changing the attributes inside the object.
at least that is what i understand by your explanation. thank you for the help.
+ 2
Sonic then i guess overloading would solve it ;)