Inheritance instance variables with Java
I am aware that if you subclass a class (superclass) that has, for example, an instance variable, it will inherit in the subclass.
i.e.
class Weather {
int humidity;
}
public class Rainy extends Weather {
void changeHumidity() {
humidity = 10;
System.out.println(super.humidity);
}
public static void main(String[] args) {
new Rainy().changeHumidity();
}
}
Bottom line: I would like to know why the instance variable "moisture" is shared between subclass and class.
I know that if I shaded this it wouldn't be generic, but still why should another instance (even if it is a superclass) have to share a variable with a subclass in inheritance logic.
Thanks in advance.
source to share
There were two decisions that the Java creators took on, guided by the way they developed Java. One of them was that execution was a priority, it shouldn't be considered unusable because it is too slow. Another solution was that they would target C and C ++ developers and make Java look like what they are used to in order to make it easier to adopt.
So Java got public, private and secure access like C ++. When the package came - private and why it's not clear by default. Perhaps they assumed that developers would want to access variables directly to save the overhead of calling the method. A long time ago I was working on a project with professionals from Marimba, and we had the opportunity to explore some of the implementation code that was written with a lot of package-private members. When I asked why the explanation was for performance. This was before optimizations such as JIT, so there might be a problem that using accessor methods for frequently used members of the superclass might be too slow. On the other hand, it may be a preference for style,or they are taking a looser approach as part of an evolving design, and perhaps the idea that package-private was the default was that this kind of freedom should be expected. (This is not something that fell into judgment on any other code I read.) It was code written by Jonathan Payne and Arthur Van Hoff, so people with professional service might not have been able to truly.
There's an interview in which James Gosling talks about his reasons :
... one of the things I wanted to do early on was formalize the setup and get something in this language. Do you know the convention in JavaBeans that you write setup methods and getter methods? But at the time, I did a bunch of developer polls about whether they wanted this. And the middle man went: "My God!"
And so I didn't. But I think in retrospect I never listened to them. I should have just done it. Because, I mean Beans, basically layered on this object, which I wanted to do anyway, but Beans did it as an afterthought.
And since it overlaps like a naming convention, there are some things that don't go well with each other. And so, for example, it would be very helpful if the default protection for an instance variable is private. And then getters and setters, which the system could know at a much deeper level to make them public or batch.
The direction in which the style evolved was to prefer private use of instance variables and, if necessary, expose them through getters. You can specify a private access modifier, for example:
private int humidity;
and then the variable will not be visible to the subclass.
source to share