We were considering a class that inherits from another:
public class Foo extends Bar {
...
}
I asked people what fields and methods Foo would have. Someone pointed out
that it would have any fields and methods declared inside of Foo. It also has
fields and methods inherited from Bar. Which ones? It seems like it would
have them all, but there are some notable exceptions.Methods that are overridden in Foo are not inherited from Bar. They can be called inside of the Foo class itself using the "super." notation, but they are not, in general, part of the Foo class.
It also turns out that private fields and methods are not inherited. This seems a bit surprising to people, but it makes sense if you think about the idea that private means private to the class. A private element should not be visible outside the class, not even to subclasses.
If there is a case where you want to expose a field or method to subclasses and only to subclasses, you should declare it to be "protected". The protected modifier is in between public and private. A protected element will not, in general, be visible to other classes unless they are subclasses.
Since we were on the subject of access modifiers, we briefly discussed the fourth possibility in Java. You can declare an element to be public, protected or private, or you can not say at all. In that case you get what is known as "package scope." A field or method that has package scope is visible to all classes in the same package.
This set of four possibilities is a bit of a mess in Java. Some Java programmers really like package scope and prefer to either make something public or to limit it to package scope. Other Java programmers like the public/protected/private hierarchy that was borrowed from C++. What we have in Java is a weird hybrid of the two. For example, protected access also includes package access, so to be correct we really should say that protected elements are available in subclasses and in all classes in the same package.
I mentioned that we hadn't covered all of the bases in terms of inherited methods and fields. Someone said that we hadn't discussed interfaces. For example, suppose our class header looks like this:
public class Foo extends Bar implements Baz {
...
}
Interfaces are allowed to have static constants and these would be inherited if
a class implements the interface. But there aren't any instance fields
inherited through interface implementation. But methods are a different
story. Every method that is mentioned in an interface is inherited by a class
that implements the interface, although you have to realize that was is
inherited is an abstract method. The class has the option of overriding the
abstract method by giving it a concrete definition. If it doesn't, then it
instead has the abstract method, which would mean that the class itself would
have to be declared as abstract:
abstract public class Foo extends Bar implements Baz {
...
}
Any class that extends this class inherits all of its methods, including the
abstract methods, unless it decides to override them. The only way to get to a
concrete class that can be instantiated is to eventually override each of those
abstract methods with a concrete definition.I then said that I wanted to spend some time talking about reflection. I showed a few quick things at the end of the lecture, but I gave a better presentation on Friday, so I'll focus on making those notes complete.