Question in K&B Book - protected class 4. Which two of the following are legal declarations for nonnested classes and interfaces? (Choose two.) A. final abstract class Test {} B. public static interface Test {} C. final public class Test {} D. protected abstract class Test {} E. protected interface Test {} F. abstract public class Test {} df
he give answer is: C, F. Both are legal class declarations. A is wrong because a class cannot be abstract and final�there would be no way to use such a class. B is wrong because interfaces and classes cannot be marked as static. D and E are wrong because classes and interfaces cannot be marked as protected.
???Classes cannot use protected.
Purujit Saha
Ranch Hand
Joined: Nov 01, 2005
Posts: 86
posted
0
A nonnested class can never be private, protected & static
A Kumar
Ranch Hand
Joined: Jul 04, 2004
Posts: 973
posted
0
Hi..
For a non-nested class/interface
class:
default,public,abstract,final
interface
default,public,abstract
Regards
dpy learn
Greenhorn
Joined: Nov 11, 2005
Posts: 4
posted
0
Thanks all
Shanel Jacob
Ranch Hand
Joined: Jun 18, 2006
Posts: 112
posted
0
Hello all,
1) Regarding the discussion above, while a top level class can be Default, Public, Abstract or Final (but not both of course): Can someone explain why a top level class "can never be private, protected & static".
2) A member/nested class can have the modifiers of top level class: Default, Public, Abstract or Final + "private, protected & static". Is this assumption correct?
Thank you.
mmg
Greenhorn
Joined: May 10, 2006
Posts: 11
posted
0
1) A class can't be: - private because then you wouldn't be able to use it - protected because this would mean that subclasses can use it. From the moment you subclass it you would be able to use it, so that doesn't make alot of sence...
2) yes, this is correct
Shanel Jacob
Ranch Hand
Joined: Jun 18, 2006
Posts: 112
posted
0
Ok makes more sense that top level class cannot be marked Private, otherwise you cannot use it.
However, what's wrong with marking top level class Protected? That just means you are restricting subclasses outside the package from accessing it eh? What's wrong with that?