Publicm, Private, Protected

P

Prabh

Hi all,
Heres a real dumb question.

I'm new to this Object-oriented programming.
Can anyone please explain to me(in English!) when do I use Public,
Private or Protected to classify my ..well, classes.

Is there a general rule of thumb?

Thanks,
Prabh.
 
M

Marco Schmidt

Prabh:
Can anyone please explain to me(in English!) when do I use Public,
Private or Protected to classify my ..well, classes.

Personally, I use public for constants, e.g. like that:

public static final int MAX_VALUE = ...;

For everything else I use private member variables, providing public
get and set methods to let users access them.

Regards,
Marco
 
J

Joe Pribele

Hi all,
Heres a real dumb question.

I'm new to this Object-oriented programming.
Can anyone please explain to me(in English!) when do I use Public,
Private or Protected to classify my ..well, classes.

Is there a general rule of thumb?

Thanks,
Prabh.
public make it accessible to everyone
private to know one
protected to classes in the same package and inherited classes.

http://www.mindprod.com/jgloss/scope.html

hows was that?

joe
 
B

Brad BARCLAY

Prabh said:
Hi all,
Heres a real dumb question.

I'm new to this Object-oriented programming.
Can anyone please explain to me(in English!) when do I use Public,
Private or Protected to classify my ..well, classes.

Is there a general rule of thumb?

There are actually four access qualifiers: public, private, protected,
and "default". "Default" is what you get when you don't specify an
access modifier.

The public modifier has the most generous access rules -- any class
anywhere can access the public entity.

The "default" modifier has the next-most generous access rules -- any
entity within the same _package_ can access the "default" entity.

The "protected" access modifier is more restrictive, in that the entity
is only accessible from within its defining class, _and_ any/all subclasses.

The "private" member is the most restrictive, in that you can only
access the private entity from within the class that defines it.

HTH!

Brad BARCLAY
 
A

Adam Maass

Brad BARCLAY said:
There are actually four access qualifiers: public, private, protected,
and "default". "Default" is what you get when you don't specify an
access modifier.

The public modifier has the most generous access rules -- any class
anywhere can access the public entity.

The "default" modifier has the next-most generous access rules -- any
entity within the same _package_ can access the "default" entity.

The "protected" access modifier is more restrictive, in that the entity
is only accessible from within its defining class, _and_ any/all
subclasses.

And also anywhere in the same package. Strange but true.
The "private" member is the most restrictive, in that you can only
access the private entity from within the class that defines it.


The rule of thumb: use the most restrictive access modifier that will get
the job done. This advice is usually taken to mean: variables should be
private, and methods public or private. Classes and interfaces intended to
be used outside the package are public; classes and interfaces to be used
only within the package are default.

Protected access only comes into play when taking advantage of
inheritence -- and classes written to be subclassed need special
consideration to make sure they will work as expected even when subclassed.


-- Adam Maass
 
B

Brad BARCLAY

Adam said:
subclasses.

And also anywhere in the same package. Strange but true.

Not according to the JLS ss6.6.2. If you are using a compiler/runtime
that permits this, then it is in error.

As such, I wouldn't go around relying on this sort of behaviour, as it
is something that could easily be "fixed" in an updated JDK.

Brad BARCLAY
 
G

ghl

Brad BARCLAY said:
Not according to the JLS ss6.6.2. If you are using a compiler/runtime
that permits this, then it is in error.

Ah, but JLS ss6.6.1 says "if the member or constructor is declared
protected, then access is permitted only when one of the following is true:
Access to the member or constructor occurs from within the package
containing the class in which the protected member is declared." [among
other things]
So same package classes are allowed to access protected members and
constructors.
 
A

Adam Maass

Brad BARCLAY said:
Not according to the JLS ss6.6.2. If you are using a compiler/runtime
that permits this, then it is in error.

Not quite. 6.6.1 states, in part:

Otherwise, if the member or constructor is declared protected, then access
is permitted only when one of the following is true:
a.. Access to the member or constructor occurs from within the package
containing the class in which the protected member or constructor is
declared.
b.. Access is correct as described in §6.6.2.
As such, I wouldn't go around relying on this sort of behaviour, as it
is something that could easily be "fixed" in an updated JDK.

Umm, no. It is part of the language specification. Compilers and runtimes
that DO NOT allow same-package access to protected members are in error.


-- Adam Maass
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top