I know that an inner class has access to everything in the outer class (because it's a member of that class) but what about the other way around?
Does the outer class have access to private variables and methods within an inner class?
I've seen articles mentioning that inner classes should be private so that they are accessible only to the outer class. What does that do to the accessibility of that inner class?
What is best practices in dealing with access levels when it comes to your inner classes? I'm assuming more encapsulation the better but does that come at the expense of accessibility?
This topic is covered in some detail by Effective Java (2nd edition) Item 22: "Favor static member classes over nonstatic".
A brief summary:
An inner class should not have access to an outer class instance, unless that access is required, i.e. inner classes should be static by default. To get technical, Effective Java calls these static member classes, as opposed to inner classes, and uses the term nested class to encompass both the static and nonstatic versions.
An outer class always has access to the members of its inner classes, even when those members are private. In this way, an inner class can expose itself only to its outer class.
"An inner class should exist only to serve its outer class."
Personally, I'm inclined to implement an inner class whenever doing so allows the inner class's constructors to be private, i.e. when a class can only be instantiated from one other (outer) class. Any additional encapsulation, such as making the entire inner class private, is desirable; but public inner classes are perfectly acceptable. There are many examples in Java, such as AbstractMap.SimpleEntry.
Related
Why can't inner classes have static (non-final) fields and methods?
This question has been posted before but the posted answers were: it's a design decision or because inner classes happen in the context of the outer class and cannot declare static methods.
Yet these answers do not clarify my question. What would be the consequences of allowing static fields and methods on inner classes? My guess is that both restrictions are connected. Since static methods would require access to other static methods and non-final static variables of the inner class or even from the outer class (to be able to change internal states), this would lead a inner class to behave like a static one. The JVM could limit access from static methods in inner classes to static methods and data inside the inner class, though. Yet this raises the question: why can't we declare static non-final variables inside inner classes?
Is this design or there are problems?
Kind regards
Declaring static variables in non-static inner class seems contradictory to intend of creating inner non-static class.
If you declaring some variables and methods static you do it when it make sense to access them without creating instance of class, if you declaring inner class non-static its instance type, so intent is to access it via its instance not staticly. If you declare inner class static, therefore separate it from outer class, you can declare variables and methods static.
You asked what would be consequences if java allowed you to declare static methods/fields in inner non-static classes. Well probably there would be none. But it just doesn't make sense, therefore it's a design choice.
To answer why... ->
Inner class object is strongly associated with Outer class object that means without existing Outer class object there is no chance of existing Inner class Object, so defining any static variable/method inside Inner class would not fulfill this requirement
In case of static nested class -> Inner class object is NOT strongly associated with Outer class object
What is the exact purpose of inner classes in Java and creating methods in it. Can I get the same behavior if I create methods in a class instead of creating those methods inside Inner class?
We can access both Inner class methods as well as instance methods outside of outer class. So what is the exact purpose of Inner classes in Java? Is there any situation/possibility where we can't survive without inner classes?
Using them greatly depends on what you need to do. Sometimes you need a class that will be only used inside of one particular class, sometimes you need to quickly create an instance of Comparator and pass it to sort() method (anonymous inner class). Some inner classes are accessible outside of the class, some aren't. There are four different varieties of nested classes in java, for more I recommend reading this: http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
Inner class does not instantiate upon outer class instantiation unless you explicitly do it in the constructor. Therefore it's methods are not useful to the rest of the class unless they are static or you have created an instance of it and using them.
If you place your methods inside the inner class they can access the inner method, instance variables! You cannot access those variables in the outer class.
you can refer to this
basically inner class keep the object oriented programming more intact.
Also sometime when you have to implement an interface which has only one unimplemented method inner class comes handy. specially anonymous inner class.
also instead of writing complicated if-else structure or switch case we can use this inner classes for callbacks
While this is obviously a RTFM case, somehow I failed to find a concise source explaining it all.
public class Outer {
private class Inner {
}
}
Private class Inner is an inner class of a public class Outer.
My question is about visibility of Inner from outside `Outer'.
Should I be able to instantiate Inner in another class? If yes, are there any limitations (like this class being in the same package, etc.)?
Can Inner be used as a concrete type when using collections? For example, should I be able to declare ArrayList <Inner> in another class?
If another class extends Outer will Inner come along in terms of the above questions?
Inner is private, therefore only its parent, Outer, can do anything at all with it.
The "FM" in this case is the Java Language Specification. You want section 6.6.1 which includes:
Otherwise, if the member or constructor is declared private, then access is permitted if and only if it occurs within the body of the top level class (ยง7.6) that encloses the declaration of the member or constructor.
So the constructor can be called anywhere within the declaration of Outer (including within any other nested classes that Outer declares), but nowhere else. Access is not inherited - it's as simple as whether the source code that's trying to call the constructor is within the source code of Outer.
If I declare a variable as private in an inner class, the variable is visible to the outer class. I am unable to understand the logic here. Shouldn't it ideally be only accessible within an inner class?
I think the answer is subjective as the question basically seems to be asking why Sun/Oracle's language designers decided to allow a certain behavior.
That said, here is an attempt at an answer...
First some terminology, a class declared within a class is a nested class. An inner class is a non-static nested class which must reside within an instance of the outer class. So the inner class is a part of the outer class and in that sense, all members of the inner class are to an extent members of the outer class.
http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
As with instance methods and variables, an inner class is associated with an instance of its enclosing class and has direct access to that object's methods and fields. Also, because an inner class is associated with an instance, it cannot define any static members itself.
Another thought is that the valid use cases for an inner class preclude the necessity to allow the inner class to hide members from the outer class. That is, there is no notion that the outer class would not be coupled to the inner class.
Why allow private at all then? Because private members can still be hidden from other classes which may gain access to an instance of an inner class.
Alright, I know it's the rule:
According to JLS: 8.1.3 Inner Classes and Enclosing Instances, inner
classes may not declare static initializers or member interfaces.
Inner classes may not declare static members, unless they are
compile-time constant fields.
According to 8.5.2 Static Member Type Declarations, "Member interfaces
are always implicitly static. It is permitted but not required for the
declaration of a member interface to explicitly list the static
modifier". They are always top-level, not inner.
I just wonder why. What may happen if we are allowed to declare interface within an inner class? Won't inner class become top-level class if I put it into another Class file?
Won't inner class become top-level class if I put it into another Class file?
No, it still is an inner class, which the filename indicates (IIRC it's OuterClass$InnerClass.class).
Inner classes have access to the outer class' attributes, i.e. they depend on their outer class' instance. With interfaces you couldn't do this. Think of a completely unrelated class that would have to be created by the corresponding outer class' instance. How would that be done if the outer class doesn't know who implements that interface?
What you can do is declare static interfaces in your outer class, thus merely using the outer as a namespace:
public class OuterClass {
public static interface InnerInterface { //protected and private would be fine too, depending on what makes sense
}
}
Edit: actually, I misread the question and since interfaces are static anyways, here's an updated code snippet:
public class OuterClass {
public static InnerClass { //static inner class making OuterClass just be a namespace
public interface InnerInnerInterface { //protected and private would be fine too, depending on what makes sense
}
}
}
As a workaround you could define an abstract inner inner class, with the drawback that you have to stick to the single inheritance constraint.
Think of it in terms of static vs. non-static context. A "top-level" class establishes a static context because it can be accessed without any enclosing instance. I.e. you can access top-level classes from a main method. The same applies to any static members of a top-level class. An inner class, however, neither exists in* nor establishes any static context. Therefore it can't have any static members, and it can only be accessed via an instance of its containing class, like constructors and other instance members. From a main method, you wouldn't be able to say Outer.Inner.SOME_FIELD because members of an inner class only have meaning with respect to the containing class.
*sort of
By definition a top level class and its inner class(es) are tightly coupled. Interfaces are a means of reducing coupling.
Inner classes are supposed to be implementation details of the top-level class and should therefore be invisible to the client. Any functionality you wish to access of an inner class should be done so through the top-level class, because conceptually speaking, that functionality should be visible only as functionality of the top-level class, so that the class designer can swap out or otherwise drastically change inner classes without breaking clients' builds.