[itistoday]

So I've been trying to learn Java recently and have read Sun's reasons for using private instead of public, but I still don't understand why anyone would want to do this.

Is there really a possiblity that someone might be able to "hack" your program because you used public instead of private?

It all seems to be a big was of time and unneccessary. Why not just use public all the time for everything since it is your own code?

[itai195]

One of the primary reasons is to enforce the abstraction boundary between interface and implementation. You might want to bone up a bit on OOP methodology to clarify that issue. Personally, I tend to use protected or the default as often as public or private. Of course, if it's all code that only you will ever have access to, you can get away with some bad practices... I still wouldn't suggest it, because those can tend to morph into serious bad habits.

[larkost]

There are two real reasons for using private methods and variables:

It prevents you from being lazy and grabbing internal things you should not (because they might act differently in different sub-classes).

It also forces you to think through how objects and classes are going to interact, and tends to nudge you towards good practices.

Some people talk about security... and there is a certain amount gained by it... but a serious decompiler can walk right through that in no time.

[Richard Edgar]

Some people talk about security... and there is a certain amount gained by it... but a serious decompiler can walk right through that in no time

In the source code, I don't think anything is gained. I don't know about Java, but in C++, the private variables are listed in the header files.... and are therefore somewhat public. As the other posters have said, it's all about enforcing the abstraction. You are prevented from messing about with internals.

Of course, if it's all code that only you will ever have access to, you can get away with some bad practices... I still wouldn't suggest it, because those can tend to morph into serious bad habits

More to the point... programs tend to exceed their design lifetimes. I know - I've been bitten by this in the past.

[itistoday]

But, in what kinds of situations would you want to restrict your own code if you're not making a library or plugin?

[larkost]

But, in what kinds of situations would you want to restrict your own code if you're not making a library or plugin?

Read my post again... it is all about organizing your thoughts, and keeping interfaces strait. Once you get beyond simple projects where you can keep everything in your head at a once you quickly need to keep things organized, and this is tool to help you do it. It is basically a method of structuring a 'best practices' method into the language so people who have not learned the lessons yet can get the idea.

If you are reaching into other objects and twiddling with their variables, then you probably don't understand object oriented programming... This is just a method of showing that. Oh... and it keeps other people working on the same project honest as well...

[itai195]

Originally posted by itistoday:
But, in what kinds of situations would you want to restrict your own code if you're not making a library or plugin?

Programmers don't generally work in isolation anymore. You don't necessarily have to be developing a library or plugin to be sharing code. The idea, like I said, is basically to enforce good software engineering principles. By enforcing an abstraction between your object's interface (public) and the implementation (private), you leave yourself the leeway to change that implementation in the future without breaking your fellow developers' code. Apple's The Objective-C Programming Language document actually has a pretty good section on this as I recall (eg encapsulation), take a look -- it applies equally to any OOP language. I don't know of any other good documents on the web about OOP but I'm sure they're around.

[Richard Edgar]

But, in what kinds of situations would you want to restrict your own code if you're not making a library or plugin?

A friendly word in your ear about programming: That program you've just finished writing? It's wrong. I don't need to know what language you've used, or what the program is meant to do. All I know is: it's wrong.

Now, you've got to fix it. In any given 'scoping unit' (for some suitably wooly definition of the term) each statement can interact with every other statement - you're looking at O(n^2) bugs, minimum. This in turn means that it's to your advantage to split the program up, and test the parts individually.

(n.b. this is just another way of rephrasing the previous two posts)

[itistoday]

Originally posted by Richard Edgar:
A friendly word in your ear about programming: That program you've just finished writing? It's wrong. I don't need to know what language you've used, or what the program is meant to do. All I know is: it's wrong.

Now, you've got to fix it. In any given 'scoping unit' (for some suitably wooly definition of the term) each statement can interact with every other statement - you're looking at O(n^2) bugs, minimum. This in turn means that it's to your advantage to split the program up, and test the parts individually.

(n.b. this is just another way of rephrasing the previous two posts)

That wasn't friendly at all... Instead of telling me that I'm simply wrong, why not try and answer the question and give me a few helpful examples (situations) where one would choose to make variables or methods or classes private?

I'm reading Sun's tutorial right now, and understand why you would make an interface public, but I don't understand why you'd make an implementation private. What if some other class needs to access another class you've made private?

[johnMG]

itistoday,

It's ok that you don't understand at the moment why it's wrong. It's not a bad thing because you are learning. What will happen is this: as your programs become more complex, you'll have more and more objects of different classes, and sometimes they will not be in the state you expect them to be in. When that happens, you'll scratch your head and say, "gee whiz, now where was the last place in my large program that I modified that object?".

If you've been directly accessing your object's data all over the place, bugs like this are very difficult to find.

If you keep your object's data private, and only access that data through methods, debugging a problem like that becomes easier -- you can just add some code in your methods for consistency checking (i.e. "*is* i == 3 before I try so-and-so?").

[Richard Edgar]

Might I suggest acquiring a sense of humour? "That program" was a generic reference. The entire first paragraph can be said to anyone about any program.

[itistoday]

Originally posted by johnMG:
itistoday,

It's ok that you don't understand at the moment why it's wrong. Keep writing programs the way your are now. It's not a bad thing because you are learning. What will happen is this: as your programs become more complex, you'll have more and more objects of different classes, and sometimes they will not be in the state you expect them to be in. When that happens, you'll scratch your head and say, "gee whiz, now where was the last place in my large program that I modified that object?".

If you've been directly accessing your object's data all over the place, bugs like this are very difficult to find.

If you keep your object's data private, and only access that data through methods, debugging a problem like that becomes easier -- you can just add some code in your methods for consistency checking (i.e. "*is* i == 3 before I try so-and-so?").

Ok, this makes it somewhat clearer. I don't know where the impression came from that I've already written programs in Java, but I haven't. I used to make programs in C, and dipped a little into Obj-C and stopped. I'm just learning Java so that's why I'm asking for specific examples.

So you say keep the variables private while the methods public? And use the public methods to access the private variables? Is that the general rule of thumb or is there more to it? What about entire classes, would I ever want to make them private?

[johnMG]

> So you say keep the variables private while the methods public?

Yes.

> And use the public methods to access the private variables? Is that the general
> rule of thumb or is there more to it? What about entire classes, would I ever want
> to make them private?

The general rule of thumb is this: keep everything as private as possible. That is, keep your variables private. Make only your public interface to your class public -- everything else should probably be private (or maybe package-private or protected in special circumstances). In your programs, make as many classes as you can package-private. Better yet, if a class is only used by one other class, make that helper class an inner class.

What you're going after here is to minimize accessibility from the outside. You want to make your program as modular as possible so users of a given class (that is, *you* while you're working on a different part of your program) don't have to know (for the moment anyway, without looking it up) what goes on inside another class -- since at the moment (while you're writing code for another part of your program) you're only a *user* of that class. If a given variable or method is private, not only don't you *need* to know about it when using the class, you're not *allowed* to use it either. :)

Well, that was kinda a mouthful, but I hope you get my point. It's definitely not obvious if you've only written small programs, but it becomes vital as programs become large. That is, when your program consists of many different classes, you'll understand how a class works while you're staring at the source code for it, but then when you're working on the rest of the program you'll forget (since you can only keep so much stuff in your head at one time). To accommodate that fact, as long as you (as a *user* of a class) *only* have to deal with its *public* interface (i.e. its public methods) you've got much less to keep in your head at one time, and there's no chance of you messing up something internal to the class.

This goes for classes as a whole, and not just methods of classes. If only a few (or one) classes in your program makes use of a some other helper class that no one else needs know about, you should consider making that class package-private rather than public.

Someone else *using* your classes (say, if your classes are all in their own namespace in some jar file, and some other programmer is making use of them by just loading the jar file (and not actually looking at your code)) doesn't want to know the details of how your classes do what they do (it would just add to complexity).

[itistoday]

johnMG,

Thank you for the explanation. Hopefully this will all become clearer to me when I start on my project, which will only have myself and perhaps one other person as programmers.

[Arkham_c]

Another point; the less you expose, the more flexibility you have when doing rewrites, refactoring, etc. In java, your public interfaces, methods, etc form a contract with classes that use them. The simpler that interface, the more you can change the underlying class without breaking things that depend on your class.

As far as security, f you have a getSuperSecretPassword() method that's public, any class with a reference to your class can call it. You probably don't want that. Again, you only expose what's necessary. And in Java, you never expose instance variables. You implement getters and setter instead.