Identifying the relationship between interface and inheritance of different classes in Java
I am trying to identify all error in coding below. There are 4 classes,
- A: Interface
- AImpl: Class implementing A
- B: Parent Class of C
C: Child Class of B
public interface A {
public void doSomeProcess(String s);
}
public class AImpl implements A {
public void doSomeProcess(String s) {
System.out.println("A Imple Code");
[. . .]
}
}
public class B {
public A doIt() {
[. . .]
}
public String execute() {
[. . .]
}
}
public class C extends B {
public AImpl doIt() {
[. . .]
}
public Object execute() {
[. . .]
}
}
Here's my understanding,
- A and AImpl are fine since A is an interface class and AImpl has to implement abstract method in A to fulfill the contract.
- Class C should be extends from Class B
public class B extends C
execute()
in Class C is overriding method
Problem is how should I deal with public A doIt()
and public AImpl doIt()
? Can an interface class be a return value?
Thanks!
java inheritance interface
New contributor
add a comment |
I am trying to identify all error in coding below. There are 4 classes,
- A: Interface
- AImpl: Class implementing A
- B: Parent Class of C
C: Child Class of B
public interface A {
public void doSomeProcess(String s);
}
public class AImpl implements A {
public void doSomeProcess(String s) {
System.out.println("A Imple Code");
[. . .]
}
}
public class B {
public A doIt() {
[. . .]
}
public String execute() {
[. . .]
}
}
public class C extends B {
public AImpl doIt() {
[. . .]
}
public Object execute() {
[. . .]
}
}
Here's my understanding,
- A and AImpl are fine since A is an interface class and AImpl has to implement abstract method in A to fulfill the contract.
- Class C should be extends from Class B
public class B extends C
execute()
in Class C is overriding method
Problem is how should I deal with public A doIt()
and public AImpl doIt()
? Can an interface class be a return value?
Thanks!
java inheritance interface
New contributor
It's perfectly OK for the overriding methoddoit()
to return a subclass of the class that the overridden method returns. It's a well-known pattern called "return-type covariance". See stackoverflow.com/questions/10134571/… . However, it's not necessary fordoit()
to return a concrete class, as it can return an interface.
– DodgyCodeException
Dec 24 at 12:23
1
Return type can be more specific in overriding methods, but can't be widened (you can use subtypes, but not supertypes). SoAImpl doIt()
is fine in C, butObject execute()
not. Lets say you haveB b = new C()
. When we callb.doIt()
we expect to get some object of class which at some point implementsA
, so if C will returnAImpl
it is acceptable. But in case ofb.execute()
we expect to getString
. IfC
will override it to allow anyObject
it could also return Integer, Animal, Car which can't be stored in String so it would break atString s = b.execute();
.
– Pshemo
Dec 24 at 12:26
add a comment |
I am trying to identify all error in coding below. There are 4 classes,
- A: Interface
- AImpl: Class implementing A
- B: Parent Class of C
C: Child Class of B
public interface A {
public void doSomeProcess(String s);
}
public class AImpl implements A {
public void doSomeProcess(String s) {
System.out.println("A Imple Code");
[. . .]
}
}
public class B {
public A doIt() {
[. . .]
}
public String execute() {
[. . .]
}
}
public class C extends B {
public AImpl doIt() {
[. . .]
}
public Object execute() {
[. . .]
}
}
Here's my understanding,
- A and AImpl are fine since A is an interface class and AImpl has to implement abstract method in A to fulfill the contract.
- Class C should be extends from Class B
public class B extends C
execute()
in Class C is overriding method
Problem is how should I deal with public A doIt()
and public AImpl doIt()
? Can an interface class be a return value?
Thanks!
java inheritance interface
New contributor
I am trying to identify all error in coding below. There are 4 classes,
- A: Interface
- AImpl: Class implementing A
- B: Parent Class of C
C: Child Class of B
public interface A {
public void doSomeProcess(String s);
}
public class AImpl implements A {
public void doSomeProcess(String s) {
System.out.println("A Imple Code");
[. . .]
}
}
public class B {
public A doIt() {
[. . .]
}
public String execute() {
[. . .]
}
}
public class C extends B {
public AImpl doIt() {
[. . .]
}
public Object execute() {
[. . .]
}
}
Here's my understanding,
- A and AImpl are fine since A is an interface class and AImpl has to implement abstract method in A to fulfill the contract.
- Class C should be extends from Class B
public class B extends C
execute()
in Class C is overriding method
Problem is how should I deal with public A doIt()
and public AImpl doIt()
? Can an interface class be a return value?
Thanks!
java inheritance interface
java inheritance interface
New contributor
New contributor
edited Dec 24 at 12:21
DodgyCodeException
3,289424
3,289424
New contributor
asked Dec 24 at 12:13
FoxForest
11
11
New contributor
New contributor
It's perfectly OK for the overriding methoddoit()
to return a subclass of the class that the overridden method returns. It's a well-known pattern called "return-type covariance". See stackoverflow.com/questions/10134571/… . However, it's not necessary fordoit()
to return a concrete class, as it can return an interface.
– DodgyCodeException
Dec 24 at 12:23
1
Return type can be more specific in overriding methods, but can't be widened (you can use subtypes, but not supertypes). SoAImpl doIt()
is fine in C, butObject execute()
not. Lets say you haveB b = new C()
. When we callb.doIt()
we expect to get some object of class which at some point implementsA
, so if C will returnAImpl
it is acceptable. But in case ofb.execute()
we expect to getString
. IfC
will override it to allow anyObject
it could also return Integer, Animal, Car which can't be stored in String so it would break atString s = b.execute();
.
– Pshemo
Dec 24 at 12:26
add a comment |
It's perfectly OK for the overriding methoddoit()
to return a subclass of the class that the overridden method returns. It's a well-known pattern called "return-type covariance". See stackoverflow.com/questions/10134571/… . However, it's not necessary fordoit()
to return a concrete class, as it can return an interface.
– DodgyCodeException
Dec 24 at 12:23
1
Return type can be more specific in overriding methods, but can't be widened (you can use subtypes, but not supertypes). SoAImpl doIt()
is fine in C, butObject execute()
not. Lets say you haveB b = new C()
. When we callb.doIt()
we expect to get some object of class which at some point implementsA
, so if C will returnAImpl
it is acceptable. But in case ofb.execute()
we expect to getString
. IfC
will override it to allow anyObject
it could also return Integer, Animal, Car which can't be stored in String so it would break atString s = b.execute();
.
– Pshemo
Dec 24 at 12:26
It's perfectly OK for the overriding method
doit()
to return a subclass of the class that the overridden method returns. It's a well-known pattern called "return-type covariance". See stackoverflow.com/questions/10134571/… . However, it's not necessary for doit()
to return a concrete class, as it can return an interface.– DodgyCodeException
Dec 24 at 12:23
It's perfectly OK for the overriding method
doit()
to return a subclass of the class that the overridden method returns. It's a well-known pattern called "return-type covariance". See stackoverflow.com/questions/10134571/… . However, it's not necessary for doit()
to return a concrete class, as it can return an interface.– DodgyCodeException
Dec 24 at 12:23
1
1
Return type can be more specific in overriding methods, but can't be widened (you can use subtypes, but not supertypes). So
AImpl doIt()
is fine in C, but Object execute()
not. Lets say you have B b = new C()
. When we call b.doIt()
we expect to get some object of class which at some point implements A
, so if C will return AImpl
it is acceptable. But in case of b.execute()
we expect to get String
. If C
will override it to allow any Object
it could also return Integer, Animal, Car which can't be stored in String so it would break at String s = b.execute();
.– Pshemo
Dec 24 at 12:26
Return type can be more specific in overriding methods, but can't be widened (you can use subtypes, but not supertypes). So
AImpl doIt()
is fine in C, but Object execute()
not. Lets say you have B b = new C()
. When we call b.doIt()
we expect to get some object of class which at some point implements A
, so if C will return AImpl
it is acceptable. But in case of b.execute()
we expect to get String
. If C
will override it to allow any Object
it could also return Integer, Animal, Car which can't be stored in String so it would break at String s = b.execute();
.– Pshemo
Dec 24 at 12:26
add a comment |
5 Answers
5
active
oldest
votes
There is no term ‘interface class’ in Java. It should be either a interface or a class.
Yes, interface could be a return type. And the benefit of polymorphism is seen in such a use-case.
add a comment |
Yes we can have a return type with interface type
For ex:
interface Bounceable
{
Bounceable isBouncing();
}
Class Tyre implements Bounceable
{
@Override
Bounceable isBouncing()
{
Bounceable myVariable;
//your code
return myVariable;
}
}
1
By almost universal convention, a method whose name starts with is should returnboolean
.
– DodgyCodeException
Dec 24 at 12:26
yups,will remember it for future answers
– iCantC
Dec 24 at 13:29
add a comment |
Problem is how should I deal with public A doIt() and public AImpl doIt()? Can an interface class be a return value?
Without any problem YES, from 1.5 version co-variant return types are allowed in overriding, i.e. if a child class is overriding a parent method, then method return type need not be of same type as parent method return type, it can be of it's child type as well.
In your case doIt()
of child method can return either of type A
or it's child AImpl
add a comment |
One major aspect of interfaces is to use them all over the place. Simply because the caller of some method doesn't need to know about the specific implementation class.
Assume that your method does return List. Most of the time, that is perfectly fine. No caller needs to worry whether the method returns an ArrayList or a LinkedList or Whatever List!
So returning A is perfectly fine, it should rather be preferred to be used!
add a comment |
Yes interface type you can use it as return type (It can hold reference to object of any class which directly or indirectly implements that interface)
In your case it's covariant return type when you are overriding doIt() method in class C.
(As overrided doIt() method's return type in class C can get upcast to return type of doIt() method in class B. it's allowed) AImpl can get upcast to A because AImpl is child of A.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
FoxForest is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53913305%2fidentifying-the-relationship-between-interface-and-inheritance-of-different-clas%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
There is no term ‘interface class’ in Java. It should be either a interface or a class.
Yes, interface could be a return type. And the benefit of polymorphism is seen in such a use-case.
add a comment |
There is no term ‘interface class’ in Java. It should be either a interface or a class.
Yes, interface could be a return type. And the benefit of polymorphism is seen in such a use-case.
add a comment |
There is no term ‘interface class’ in Java. It should be either a interface or a class.
Yes, interface could be a return type. And the benefit of polymorphism is seen in such a use-case.
There is no term ‘interface class’ in Java. It should be either a interface or a class.
Yes, interface could be a return type. And the benefit of polymorphism is seen in such a use-case.
answered Dec 24 at 12:23
Rauf Agayev
356
356
add a comment |
add a comment |
Yes we can have a return type with interface type
For ex:
interface Bounceable
{
Bounceable isBouncing();
}
Class Tyre implements Bounceable
{
@Override
Bounceable isBouncing()
{
Bounceable myVariable;
//your code
return myVariable;
}
}
1
By almost universal convention, a method whose name starts with is should returnboolean
.
– DodgyCodeException
Dec 24 at 12:26
yups,will remember it for future answers
– iCantC
Dec 24 at 13:29
add a comment |
Yes we can have a return type with interface type
For ex:
interface Bounceable
{
Bounceable isBouncing();
}
Class Tyre implements Bounceable
{
@Override
Bounceable isBouncing()
{
Bounceable myVariable;
//your code
return myVariable;
}
}
1
By almost universal convention, a method whose name starts with is should returnboolean
.
– DodgyCodeException
Dec 24 at 12:26
yups,will remember it for future answers
– iCantC
Dec 24 at 13:29
add a comment |
Yes we can have a return type with interface type
For ex:
interface Bounceable
{
Bounceable isBouncing();
}
Class Tyre implements Bounceable
{
@Override
Bounceable isBouncing()
{
Bounceable myVariable;
//your code
return myVariable;
}
}
Yes we can have a return type with interface type
For ex:
interface Bounceable
{
Bounceable isBouncing();
}
Class Tyre implements Bounceable
{
@Override
Bounceable isBouncing()
{
Bounceable myVariable;
//your code
return myVariable;
}
}
answered Dec 24 at 12:23
iCantC
262
262
1
By almost universal convention, a method whose name starts with is should returnboolean
.
– DodgyCodeException
Dec 24 at 12:26
yups,will remember it for future answers
– iCantC
Dec 24 at 13:29
add a comment |
1
By almost universal convention, a method whose name starts with is should returnboolean
.
– DodgyCodeException
Dec 24 at 12:26
yups,will remember it for future answers
– iCantC
Dec 24 at 13:29
1
1
By almost universal convention, a method whose name starts with is should return
boolean
.– DodgyCodeException
Dec 24 at 12:26
By almost universal convention, a method whose name starts with is should return
boolean
.– DodgyCodeException
Dec 24 at 12:26
yups,will remember it for future answers
– iCantC
Dec 24 at 13:29
yups,will remember it for future answers
– iCantC
Dec 24 at 13:29
add a comment |
Problem is how should I deal with public A doIt() and public AImpl doIt()? Can an interface class be a return value?
Without any problem YES, from 1.5 version co-variant return types are allowed in overriding, i.e. if a child class is overriding a parent method, then method return type need not be of same type as parent method return type, it can be of it's child type as well.
In your case doIt()
of child method can return either of type A
or it's child AImpl
add a comment |
Problem is how should I deal with public A doIt() and public AImpl doIt()? Can an interface class be a return value?
Without any problem YES, from 1.5 version co-variant return types are allowed in overriding, i.e. if a child class is overriding a parent method, then method return type need not be of same type as parent method return type, it can be of it's child type as well.
In your case doIt()
of child method can return either of type A
or it's child AImpl
add a comment |
Problem is how should I deal with public A doIt() and public AImpl doIt()? Can an interface class be a return value?
Without any problem YES, from 1.5 version co-variant return types are allowed in overriding, i.e. if a child class is overriding a parent method, then method return type need not be of same type as parent method return type, it can be of it's child type as well.
In your case doIt()
of child method can return either of type A
or it's child AImpl
Problem is how should I deal with public A doIt() and public AImpl doIt()? Can an interface class be a return value?
Without any problem YES, from 1.5 version co-variant return types are allowed in overriding, i.e. if a child class is overriding a parent method, then method return type need not be of same type as parent method return type, it can be of it's child type as well.
In your case doIt()
of child method can return either of type A
or it's child AImpl
answered Dec 24 at 12:24
raviraja
475211
475211
add a comment |
add a comment |
One major aspect of interfaces is to use them all over the place. Simply because the caller of some method doesn't need to know about the specific implementation class.
Assume that your method does return List. Most of the time, that is perfectly fine. No caller needs to worry whether the method returns an ArrayList or a LinkedList or Whatever List!
So returning A is perfectly fine, it should rather be preferred to be used!
add a comment |
One major aspect of interfaces is to use them all over the place. Simply because the caller of some method doesn't need to know about the specific implementation class.
Assume that your method does return List. Most of the time, that is perfectly fine. No caller needs to worry whether the method returns an ArrayList or a LinkedList or Whatever List!
So returning A is perfectly fine, it should rather be preferred to be used!
add a comment |
One major aspect of interfaces is to use them all over the place. Simply because the caller of some method doesn't need to know about the specific implementation class.
Assume that your method does return List. Most of the time, that is perfectly fine. No caller needs to worry whether the method returns an ArrayList or a LinkedList or Whatever List!
So returning A is perfectly fine, it should rather be preferred to be used!
One major aspect of interfaces is to use them all over the place. Simply because the caller of some method doesn't need to know about the specific implementation class.
Assume that your method does return List. Most of the time, that is perfectly fine. No caller needs to worry whether the method returns an ArrayList or a LinkedList or Whatever List!
So returning A is perfectly fine, it should rather be preferred to be used!
answered Dec 24 at 12:25
GhostCat
88.1k1684144
88.1k1684144
add a comment |
add a comment |
Yes interface type you can use it as return type (It can hold reference to object of any class which directly or indirectly implements that interface)
In your case it's covariant return type when you are overriding doIt() method in class C.
(As overrided doIt() method's return type in class C can get upcast to return type of doIt() method in class B. it's allowed) AImpl can get upcast to A because AImpl is child of A.
add a comment |
Yes interface type you can use it as return type (It can hold reference to object of any class which directly or indirectly implements that interface)
In your case it's covariant return type when you are overriding doIt() method in class C.
(As overrided doIt() method's return type in class C can get upcast to return type of doIt() method in class B. it's allowed) AImpl can get upcast to A because AImpl is child of A.
add a comment |
Yes interface type you can use it as return type (It can hold reference to object of any class which directly or indirectly implements that interface)
In your case it's covariant return type when you are overriding doIt() method in class C.
(As overrided doIt() method's return type in class C can get upcast to return type of doIt() method in class B. it's allowed) AImpl can get upcast to A because AImpl is child of A.
Yes interface type you can use it as return type (It can hold reference to object of any class which directly or indirectly implements that interface)
In your case it's covariant return type when you are overriding doIt() method in class C.
(As overrided doIt() method's return type in class C can get upcast to return type of doIt() method in class B. it's allowed) AImpl can get upcast to A because AImpl is child of A.
answered 2 days ago
Koustubh Mokashi
635
635
add a comment |
add a comment |
FoxForest is a new contributor. Be nice, and check out our Code of Conduct.
FoxForest is a new contributor. Be nice, and check out our Code of Conduct.
FoxForest is a new contributor. Be nice, and check out our Code of Conduct.
FoxForest is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53913305%2fidentifying-the-relationship-between-interface-and-inheritance-of-different-clas%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It's perfectly OK for the overriding method
doit()
to return a subclass of the class that the overridden method returns. It's a well-known pattern called "return-type covariance". See stackoverflow.com/questions/10134571/… . However, it's not necessary fordoit()
to return a concrete class, as it can return an interface.– DodgyCodeException
Dec 24 at 12:23
1
Return type can be more specific in overriding methods, but can't be widened (you can use subtypes, but not supertypes). So
AImpl doIt()
is fine in C, butObject execute()
not. Lets say you haveB b = new C()
. When we callb.doIt()
we expect to get some object of class which at some point implementsA
, so if C will returnAImpl
it is acceptable. But in case ofb.execute()
we expect to getString
. IfC
will override it to allow anyObject
it could also return Integer, Animal, Car which can't be stored in String so it would break atString s = b.execute();
.– Pshemo
Dec 24 at 12:26