I have a very basic doubt about Java Interfaces and inheritance.
Suppose I have two classes A and B and one interface C with following definitions
interface C{
public void check();
}
class A implements C{
public void check(){
System.out.println("A");
}
}
class B extends A implements C{
// Is the following method overriding the method from class A or implementing the method from C?
public void check(){
System.out.println("B");
}
}
I am confused that whether it is over-riding or implementation of check() method in class B?
It does both, they are not mutually exclusive. The purpose of an interface is to define a method signature that should be available inside the implementing class.
You should annotate the method with #Override though, it's just good form because it makes clear that it comes from a baseclass and it'll guard you against accidental typos.
As #Jeroen Vannevel and #EJP have mentioned above it's both overriding and implementing.
In order to understand this I think you need to see it in the context of compile/run time.
You have the following possible scenarios:
C c = new B();
c.check();
At compile-time you see C#check() (you can use your IDE to get you where c.check() points to) at runtime you see the overridden B#check()
A a = new B();
a.check();
At compile-time you see A#check() (you can use your IDE to get you where c.check() points to) at runtime you see the overridden B#check()
B b = new B();
b.check();
At compile-time you see B#check() (you can use your IDE to get you where c.check() points to) at runtime you see the overridden B#check()
If alternatively you are passing the method call directly in a method:
someMethod(new B().check())
then this equates the last of the above scenarios
It is both over-riding and implementing.
In your example:
class B extends A implements C{
// Is the following method overriding the method from class A or implementing the method from C?
public void check(){
System.out.println("B");
}
}
You are defining the check method in interface C as:
public void check(){
System.out.println("B");
You are allowed to do this as interfaces don't contain the definition of the method in the interface when they are created and can thus be used over and over again for things which are similar enough to use the same method with a few tweaks.
Related
I show written by me example, it is caused by the fact that I don't understand some thing in java puzzlers:
public class A {
public A foo() {return new A();}
}
package library;
public class C extends A {
static class X extends A {}
#Override
public A foo(){
return new X();
}
}
package library;
public class B extends A {
public static class Y extends A { }
#Override
public A foo(){
return new Y();
}
}
package client;
import library.A;
import library.B;
import library.C;
class Client {
public static void main (String[] args){
A b = new B();
A c = new C();
A bb = b.foo();
A cc = c.foo();
cc.hashCode(); // for me, it should causes compile error
}
}
As you can see, foo method is public.
A cc = c.foo(); - cc is instance of non-public type X
A bb = b.foo(); - bb is instance of public type Y
So, when we invoke cc.hashCode() we invoke public method from non-public type which comes from different package. Why does it is correct?
Why I think so ?
In java puzzlers book I found:
You cannot legally access a member of nonpublic type from another
package.
Moreover,
You can avoid this whole category of problem if you use reflection
only for instantiation and use interfaces to invoke methods from the
class that implements them and provides a high level of type-safety.
Can anyone explain it ? What does it mean in human-language?
Can anyone explain it ? What does it mean in human-language?
Explanation:
The Java Puzzlers book is probably referring to something else. (But who knows: you haven't given us the context.)
The Java Puzzlers book is not designed to be a specification, textbook or tutorial for the Java language. We should therefore not try to use it as such ... and we should not treat its explanations as either complete or definitive.
In fact you can call methods of a non-public class if they implement or override methods declared in a public superclass or interface of the non-public class.
The technical explanation is that
A cc = c.foo();
is accessing a foo() method that is declared in A ... which is a public class. The fact that foo() is overridden in a non-public class does not make the overriding method non-accessible. And if it did, that would violate the principle of substitutability which is principle that makes polymorphism1 work.
Or to put it more simply.
c is an instance of A.
Every A has a foo() method.
Anything to which the declaration of A::foo() is visible must be able to see the method on any instance of A.
If it can see it, it can invoke it.
1 - Strictly speaking, we are talking about subtype polymorphism here. There are other kinds of polymorphism as well to which LSP does not apply.
Java code:
class P {
public void hello() {}
}
class C extends P {
public void hello(String s) {}
}
My question is: Is the hello in class C overloading the one with same name in super class P?
My friend says they are not because the are not in the same class.
Taking a more formal approach, the Java Language Specification for Java 7 states:
If two methods of a class (whether both declared in the same class, or both inherited by a class, or one declared and one inherited) have the same name but signatures that are not override-equivalent, then the method name is said to be overloaded.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.9
I would point your friend to this link.
So, in short, in your example, the hello method is indeed overloaded.
Simple Explanation:
I think this question arises because at times we hear the following,
"Method overloading is performed within class.
Method overriding occurs in two classes that have inheritance relationship."
The above statement is correct. But your friend is wrong. why?
Because when you extend a class, the subclass have all the methods defined by superclass. It is as if all the methods of superclass have been implemented by the subclass. That means the hello() method has been implemented by the class C as well. Now, you added a method in class C with different parameter (hello(String s)). That means, class C has two methods in all with same name but different parameters and that is "overloading".
Hope it is crystal clear.
Overloading can happen in same class as well as parent-child class relationship whereas overriding happens only in an inheritance relationship.
Yes, your friend is wrong because he thinks only of the concept of overriding.
But here hello(), and hello(String s) are different by there parameters so it's overloading not overriding.
Source of confusion: Your friend would be right if speaking about C++ not Java. In C++, function overloading can only occur between members of the same class. Whereas in Java, overloading can occur, in addition to that, across two classes with inheritance relationship.
Yes it is overloading, This overloading is happening in case of the class 'C' which is extending P and hence having two methods with the same name but different parameters leading to overloading of method hello() in Class C. However Class P is only able to access one of the methods which is present in its own definition.
Long story short, an instance of C will have both the hello() and the hello(String s) methods available. An instance of P will only have the hello method available.
This is indeed overloading, as you have two methods of the same name taking different parameters.
However, it is not overriding, because overriding is having a method declared in a subclass with the same name and same parameters as a method in a superclass.
E.g. if you had
class C extends P {
public void hello() {}
}
it would be overriding the hello() method declared in P. When invoking new C().hello() in that case, you would invoke the implementation of the hello() method declared in class C.
It is a valid question since usually, overloading is explained using two methods with the same name (but different parameters) in the same class.
I would argue that yes, the method hello in C is overloading P's hello method because of the "is a" relation.
The "is a" relation states that since C subclasses P, it is also an instance of P ("C is a P"). Hence C has 2 overloaded hello-methods.
Good question!!!In sub class if method name | parameter type | list is changed then sub class method will not be considered as overriding it is considered as overloading method
Example :
class A{
void m1(int a){}
}
class B extends A{
void m1(float f)
{}
}
In above program m1 method is a overloaded method.
Yes we can overload the super class method in sub class like as bellow:
public class OverLoading {
public static void main(String[] args) {
B b = new B();
b.display();
b.display(4);
}
}
class A {
public void display() {
System.out.println("A class display method");
}
}
class B extends A {
public void display() {
System.out.println("class B subclass");
}
public void display(int a) { //Overloading in subclass
System.out.println("class B subclass with overloading");
}
}
Output:
class B subclass
class B subclass with overloading
Depends on the class. From class P's perspective (if the reference is P, the object can be of C) it is not. If you write something like: P p = new C(); there is no overloading because you cannot call p.hello("foo").
From class C's perspective it is overloaded because if you write C c = new C(); it has two methods with same name and different signatures.
This is a good question and the answer is a bit tricky.
Well, it's true that you can overload an inherited method from a parent class into a subclass. However, and here's the interesting part, the actual behavior depends on the reference variable type.
Let's consider the following example:
public class OverLoadingTest {
public static void main(String[] args) {
ChildClass cc = new ChildClass();
SuperClass sc = cc;
sc.method("lol");
cc.method("lol");
}
static class SuperClass {
public void method(Object o) {
System.out.println("SuperClass called.");
}
}
static class ChildClass extends SuperClass {
public void method(String s) {
System.out.println("ChildClass called.");
}
}
}
So, we have a class extending another and with a method that overloads a method from the parent.
It's easy to guess that if you have an instance of ChildClass, the two methods are overloaded, and overloading resolution takes place as it normally does.
However, let's consider creating an instance of ChildClass and assigning it to a reference variable of type SuperClass. Is the overloading thing still standing?
If you execute this program you will get this outptut:
SuperClass called.
ChildClass called.
The output clearly indicates that there's no overloading here in this case. This however can be altered by overriding the original method.
static class ChildClass extends SuperClass {
public void method(String s) {
System.out.println("ChildClass called.");
}
public void method(Object o) {
System.out.println("ChildClass called.");
}
}
Now, if you run the program again, you get this output:
ChildClass called.
ChildClass called.
Explanation
Now, why is JVM behaving that way? Why can't it see the overloading method as we're using an instance of the child class?
This takes us to how does JVM call a method. The JVM sees that you're referring to the object with a reference of type SuperClass, so, it can only use the methods that are related to that type, with the only exception is overriden methods. And since method(String) isn't overriding, we have method(Object) of the parent, hence, it's the one chosen for execution.
We then override the method to break this rule, and this is how the JVM called ChildClass.method(Object) even if the reference variable is of a parent class.
Overloading is when you have two methods that have the same name but different signatures (Your case).
Side note: Overriding is when you have two methods that have exactly the same signature and name and the parent class.
How exactly is inheritance implemented in Java? For example, consider this:
class A {
public void foo() {
System.out.print("A");
}
}
class B extends A {
...
}
class Test {
public static void main(String[] args) {
B test = new B();
test.foo(); // how is foo() called?
}
Below the line, would the compiler just dump the definition of A.foo() into the body of class B? Like
class B extends A {
...
public void foo() {
System.out.print("A");
}
}
Or is foo somehow looked up in class A and called there?
This may be able to assist you, explanation from the book Ivor Horton's Begining Java 7
I said at the beginning of this chapter that a derived class extends a base class. This is not just jargon — it
really does do this. As I have said several times, inheritance is about what members of the base class are
accessible in a derived class, not what members of the base class exist in a derived class object. An object of
a subclass contains all the members of the original base class, plus any new members that you have defi ned
in the derived class. This is illustrated in Figure 6-3.
Method bodies aren't copied in the undefined method body of a subclass. Instead, when you call
B test = new B();
test.foo();
It will look trough its hierarchy, going up a level every time it can't find an implementation.
First it will check B which has no implementation. One level above that there's A which does, so it will use that one.
As shown in http://docs.oracle.com/javase/tutorial/java/IandI/override.html, Java does allow
Overriding an instance method by an instance method and
Hiding a static method by a static method
My question is why Java doesn't allow hiding a static superclass method by an instance method. This could be done like this:
class Base {
static void foo () {}
}
class Derived extends Base {
void foo () {}
void access () {
foo ();
Base.foo ();
}
}
I don't see any particular issue with the above approach - it is only as "messy/complex" as the (allowed) hiding of statics already is.
I suspect it is to avoid confusion with dealing with the base class. In fact I imagine the designers didn't see an obvious way this should behave.
class Base {
static void foo () {}
}
class Derived extends Base {
void foo () {} // say this compiled
}
Base b = new Derived()
b.foo(); // should the static or the virtual method be called?
Should b.foo() call Base.foo() or should it potentially call Derived.foo()?
Simple answer: that would be the mess.
Concrete answer: what to call in that case Derived.foo()? Base.foo() can't be called as it's hidden (as per you), Derived.foo() can't be called as it's not static.
Because, one are like Bananas and the other ones are Apples.
Explaination:
Static Methods are created when reading the Class-Structure
Methods are created when a object of a class is created.
Example:
Foo.bar();
is something different than
new Foo().bar();
Guess which one is called?
Foo f = new Foo();
f.bar();
Another to add here is:
1. Static methods belong at the class level. So u cannot override method in the derived class.
as simple its called hiding. :)
2. Instance methods belong to the objects, so objects are overrided. So we can override in the derived class.
Above other comments give a good example have a look into it..
Regards
Punith
I sometimes write classes which can be converted to- and from- something else, and I'm used to writing it as a non-static convert-to method and a static convert-from method, for example:
class A {
B toB() {...}
static A fromB(B b) {...}
}
or
class B {
void save(File f) {...}
static B load(File f) {...}
}
I used to think it's a good and simple approach, but lately the static-ness of the conversion-from method has been annoying me, for instance if I want to define an interface for types that can be converted to- and from- B:
interface ConvertableToAndFromB {
B toB();
// ?
}
So, is there an elegant way of doing that without having the conversion-from as static, other than migrating to Smalltalk?
EDIT
To clarify, I realize I can add a non-static method in the interface, e.g.:
interface ConvertableToAndFromB {
B toB();
void fromB(B b);
}
or, if I want to allow immutable types (thanks Stripling):
interface ConvertableToAndFromB<T implements ConvertibleToAndFromB<T>> {
B toB();
T fromB(B b);
}
But that will require me to create a new A before I can even invoke this, as in:
A a = new A();
a.fromB(b);
or (for immutable):
A a = new A();
a = a.fromB(b);
which is what I'm trying to avoid (but will do with no other solution). I just hope there's a nicer way.
You should be able to make your interface recursively generic. I believe the syntax is like this:
interface ConvertibleToAndFromB<T implements ConvertibleToAndFromB<T>>{
B toB();
T fromB(B b);
}
class A implements ConvertibleToAndFromB<A> {
B toB() {...}
A fromB(B b);
}
Making things more strongly typed like this has obvious advantages. However, it does mean that you have to be somewhat aware of the actual type that you want when you call fromB. There are advantages and disadvantages to this approach.
As a side note, making A responsible for generating objects of type A or B violates the Single Responsibility Principle, and I would generally prefer to have a separate Converter class or interface to perform these actions.
Converter<A, B> converter = converterFactory.get<A, B>(A.class, B.class);
B b = converter.from(a);
Often, a fromB method would be implemented as a copy constructor. E.g.
public class A
{
public A(B b)
{
this.someValue = b.someOtherVariable;
}
}
Unfortunately this does not help you create an interface to abstract said functionality. Normally, a separate factory could be used, and this factory implement an interface, but this would still not allow you to get around being able to implement the method in your object in a non-static way while avoiding unnecessary instantiation.
In your scenario, I'll do it this way:
interface ConvertableToA {
A toA() {...}
}
interface ConvertableFromA {
Object fromA(A a) {...}
}
class MyConvertableClass implements ConvertableToA, ConvertableFromA {
...
}
creating a utility helper class might be better because if you think about it, conversation has nothing to do with the object/instance.
for example, when you convert an array to list, you don't do arr.asList(), rather, you use Arrays.asList(arr)