This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I know that the Protected access specifier fields can be accessed within same class, sub-class and same package and defualt access specifier fields can be accessed withing same class, and same package only.
But why i'm able to acess the default specifier fields with sub-class also ? (see the screen shot attached)
Am i doing something wrong here ? please tell me, it is very important to clear this basic.
Also, your example doesn't illustrate what you are trying to check. In Derived#display, you shouldn't have Base base=new Base(); You should have :
Joined: Aug 30, 2009
hi Christophe Verré , i have got your point that
If I were you, I'd wonder what would happen if the subclasses were in a different package than their parent.
i tried with another class found that default fields cannot be accessed from a sub-class(residing in a different package that of its parent class) but can be accessed withtin a sub-class if both parent and child are in same package only.
Now my next question is then what is difference between Protected and Default. Don't you think so that both are behaving similarly ?
Protected and default access have to very different purposes.
You need to understand how important the notion is that a class member can be accessed outside of a package. Default access makes a member visible to any class that is inside the same package *only*.
Protected access means that the member can be accessed outside of the package, even if it is only by subclasses. This difference is very great.
Think of a package as something that is yours. If there is something inside this package that the rest of the world can't see, then it will make it very easy for you to change this thing later on.
However, if there is something in your package that is either public or protected, then the rest of the world can see it, and it can write code that depends on it. From this point on you have a commitment to never change what this piece of your package does, or it will break the code of someone else who depends on it.
I believe that you should almost always favour composition over inheritance. I declare all my classes final, unless I design them explicitly to be extended.
In practice, for now I would suggest going by my rule of thumb:
Use private and default access as you please. You can never go wrong with them.
Never use protected. You need to have a very clear idea of what you are designing if you are going to need protected access.
Use public sparingly. Only if the outside world needs access to a piece of your package.
If you want a great example of good use of protected, take a look at FilterInputStream and all its subclasses. These classes were designed to be inherited, and are clearly documented.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.