When do you make object private

All

In HeadFirst Java (Book) on Page 507, what we are achiving by makeing account object private. How does it matter, if it was not explictily made private.

Thanks
Anu

Welcome to JavaRanch!

For the answer, I suggest you turn all the way back to page 81 and review the topic, "Hide the data."

Hi Anu,

You define a member variable or method as "private", when you want to hide then from all the code that exists outside of the class you are working on (let's call it MyClass).

This way, other classes that use your class won't have to be changed when you change private variables and methods in MyClass. Because they could not use it directly anyway.

You cannot use directly something you cannot see.

HTH

Thanks for the response. I understand access modifier. But My question, per author comments on Page 507, there will be only once instance of bank account. Does making private, help you to ensure there will be only once instance (we are not implemnting singleton in this example).

If we reomve the private, while amke the account object . Then will we different instace of the account object in different threads.

Please help.

Thanks
Anu

Originally posted by Anu Daga:
...Does making private, help you to ensure there will be only once instance (we are not implemnting singleton in this example)...

No, a private variable does not limit the number of instances created. I will need to look at the book when I get home tonight to see what the reasoning is. But you mentioned threads, so I'll venture a guess now...

If the variable is private, then the only way for other objects to access the instance is through mutator ("getter" and "setter") methods. And if the mutator methods are synchronized, then any thread trying to invoke the method must first obtain the lock.

Originally posted by marc weber:
...you mentioned threads, so I'll venture a guess now...

If the variable is private, then the only way for other objects to access the instance is through mutator ("getter" and "setter") methods. And if the mutator methods are synchronized, then any thread trying to invoke the method must first obtain the lock.

Yes, now that I'm looking at the book, this does seem to be the reasoning. There are 2 threads that might be trying to access this account at the same time. The lock is introduced on page 509, and the "synchronized" keyword on page 510.

If each thread had its own account, then there wouldn't be a problem. The significance of there being only one account is that both threads are sharing the same resource, which raises the potential for problems (as illustrated on p. 508).

Again, this goes back to the idea of hiding the data and using "getters" and "setters" (pp. 79-82). By making the fields private, the only way to get to the data is through the methods. And the methods allow you to add more controls -- for example, validating and synchronizing.
[ March 26, 2007: Message edited by: marc weber ]