oop - Bloch Effective Java - favor static classes over nonstatic - how many instances? -
I want to know how many static member classes can be created by the enclosed class. I only accept one, but I do not understand the following conclusions from Bloch.
Following the Effective Java of Joshua Bloch - Item 22 *: Follow Static Member Sections on Non-permanent.
A common use of the private station member classes is to represent the component of the object presented by their attached class. For example, consider the map example, which combines the keys with values, there is an internal entry object to apply multiple maps to each key-value pair in the map. While each entry is associated with a map, the methods of an entry (getKey, getValue and setValue) are not required to access the map. Therefore, it is useless to use a non-member member class to represent the entries: A personal stable member class is the best. If you accidentally leave the static modifier in the entry declaration, then the map will still work, but each entry will have an overlapping reference to the map, which will waste space and time.
He states that the map creates an entry object for every key-value pair in the map, i.e. many examples of static member class
So my assumption is wrong! This means that my understanding of a permanent member class is wrong. Everyone knows how a stable member behaves in a variable, for the classic static final string example - there is only one example of the object
Does this mean that a stable member class is not really immediate When is the enclosed object turned on?
In that case, what does the map mean by using the static member class for the entry? Why not just use an interface on the API? Every other collection class could just provide its own implementation.
[*] Just realized that this book is in the PDF version of 18. I
< P> I think the Java team had messed up on this one. A static inner class (strictly called its "exact static nested class") is no different from a simple class, except that the fancy name (MyClass instead of
Something.MyClass Code>) and private (i.e. not immediately from other classes).
In the case of
map , it was chosen entirely because name
map. Entry makes it clear that
entry belongs to
map . As you suggest, it would be perfectly appropriate for this to use a simple class. The only difference is that you do not want to write
Map.Entry .
I think what they should have done, the syntax for "non-stationary" internal orbits (i.e. only one
class in a affiliate class because <+> static was chosen to avoid too many reserved keywords, but I think it only encourages confusion.
Comments
Post a Comment