allelopath
asked on
abstract method in abstract class
If I have a class like so:
public abstract class MyClass {
public abstract myMethod();
}
Then when a class extends MyClass, must it implement myMethod?
I thought it did not, that being one of the differences between an abstract class and an interface,
but I am getting a compile saying the myMethod must be implemented.
public abstract class MyClass {
public abstract myMethod();
}
Then when a class extends MyClass, must it implement myMethod?
I thought it did not, that being one of the differences between an abstract class and an interface,
but I am getting a compile saying the myMethod must be implemented.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The fundamental is plain and simple.
An interface can have methods which are only abstract, we cannot have concrete definition of the method, only the declaration part.
Where as in Abstract class, we have concrete methods as well as abstract methods. The abstract methods are to be implemented in the child class unless the child class is again abstract.
so in your case, if your abstract method is like:
public abstract class MyClass {
public abstract void myMethod();
public void print(){
System.out.println("print in MyClass ");
}
}
public class MyImplementation extends MyClass {
public void myMethod(){
//Do something
}
}
If I have the classes as defined above, then the child class, MyImplementation will have to implement the method myMethod() where as print method will be aavailable directly via the parent class (MyClass).
Hope this explains the concept.
An interface can have methods which are only abstract, we cannot have concrete definition of the method, only the declaration part.
Where as in Abstract class, we have concrete methods as well as abstract methods. The abstract methods are to be implemented in the child class unless the child class is again abstract.
so in your case, if your abstract method is like:
public abstract class MyClass {
public abstract void myMethod();
public void print(){
System.out.println("print in MyClass ");
}
}
public class MyImplementation extends MyClass {
public void myMethod(){
//Do something
}
}
If I have the classes as defined above, then the child class, MyImplementation will have to implement the method myMethod() where as print method will be aavailable directly via the parent class (MyClass).
Hope this explains the concept.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
:-)
k.
Correct krakatoa, never said what ever I said was all about interface and abstract classes, there is lot more to it, but by the way, we cannot have "concrete" methods in Interfaces, the methods are by default abstract, even if we don't define them explicitly, and abstract classes "May" contain the concrete methods, thats the basic difference between interfaces and abstract classes. Thats the precise point where the author was confused. Wonder why you found such a simple straight forward basic concept confusing.
>> Not I - you.
;)
;)
Should read :
>>Wonder why you found such a simple straight forward basic concept confusing.
Not I, you.
>>Wonder why you found such a simple straight forward basic concept confusing.
Not I, you.
ME, naaah, sorry, I am not confused, I have a clear idea about it, and my concepts regarding Java are pretty much good, or else, would not have been a programmer. you need to revisit a few concepts in that case :)
It would be interesting humanonomics, if you could kindly show us the Java docs wherein the word "abstract" is ever used by the Java authors in conjunction with the formal description of an interface or its methods. ;)
If you have trouble finding that evidence, then perhaps you'd allow me to help you : it is not there precisely because the term 'abstract' is not one which has or should be applied in even *illustrative* terms to an interface, because using it like that would cause tremendous confusion - leading to unfortunate terminological misapplications such as yours. :P
If you have trouble finding that evidence, then perhaps you'd allow me to help you : it is not there precisely because the term 'abstract' is not one which has or should be applied in even *illustrative* terms to an interface, because using it like that would cause tremendous confusion - leading to unfortunate terminological misapplications such as yours. :P
Aaah is it. Then you don't what abstract means in that case. No point in arguing. I am not in here to fight. But you have serious conceptual problems.
Well in any case the evidence.
http://forum.java.sun.com/thread.jspa?threadID=582104&messageID=2962845 (the first response).
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html (Read the statement in "Note" in centre of page).
I guess that is enough evidence.
I never say things I am not sure of, but I can surely go wrong, so thanks for pointing that out, and before arguing, please make sure that you have proper conceptual knowledge about the subject.
Thanks
Well in any case the evidence.
http://forum.java.sun.com/thread.jspa?threadID=582104&messageID=2962845 (the first response).
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html (Read the statement in "Note" in centre of page).
I guess that is enough evidence.
I never say things I am not sure of, but I can surely go wrong, so thanks for pointing that out, and before arguing, please make sure that you have proper conceptual knowledge about the subject.
Thanks
BTW it took me 2 mins precisely to find this out. Wonder how you missed out on that ? :-) @ Krakatoa
The first link is to a forum, so that's not really any more substantial than where we are now. The second link, (which is to a URL I'd quoted in a comment myself anyway), is not fully qualified just from that context; it must be considered in light of this :
"9.1.1.1 abstract Interfaces
Every interface is implicitly abstract. This modifier is obsolete and should not be used in new programs.", quoted from :
http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html
Note 'should not' - not 'can' or 'could'.
For this reason, I spoke about the highly misleading and obviously unnecessary tautology of using the term 'abstract' in connection with interfaces. The *concept* (i.e. in a thinking space outside Java formality) of an interface's method signtaures may indeed be considered abstract, but using this term in formal coding (see above) practice, or using it illustrative of an interface's methodological constitution is wrong because it literally lacks meaning and is formally ruled out.
Additionally, you were again unclear in your earlier post with :
>>If I have the classes as defined above, then the child class, MyImplementation will have to implement the method myMethod() where as print method will be aavailable directly via the parent class (MyClass).<<
There is no 'whereas' about it : the child class can access the parent print() method in any case. You imply that print() is only accessible to the parent - which is incorrect.
"9.1.1.1 abstract Interfaces
Every interface is implicitly abstract. This modifier is obsolete and should not be used in new programs.", quoted from :
http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html
Note 'should not' - not 'can' or 'could'.
For this reason, I spoke about the highly misleading and obviously unnecessary tautology of using the term 'abstract' in connection with interfaces. The *concept* (i.e. in a thinking space outside Java formality) of an interface's method signtaures may indeed be considered abstract, but using this term in formal coding (see above) practice, or using it illustrative of an interface's methodological constitution is wrong because it literally lacks meaning and is formally ruled out.
Additionally, you were again unclear in your earlier post with :
>>If I have the classes as defined above, then the child class, MyImplementation will have to implement the method myMethod() where as print method will be aavailable directly via the parent class (MyClass).<<
There is no 'whereas' about it : the child class can access the parent print() method in any case. You imply that print() is only accessible to the parent - which is incorrect.
yes, you only said "Every interface is implicitly abstract" and I had mentioned in one of my comments "the methods are by default abstract, even if we don't define them explicitly", and as far as my English knowledge is concerned, either of the statements mean the same. And I never said, that we have to define methods in interface as abstract.
Regarding the Second statement, again you are misreading it. You are the one who is getting confused out here.
Does not make sense to me the way you are arguing. And I don't get whats your problem in life.
Regarding the Second statement, again you are misreading it. You are the one who is getting confused out here.
Does not make sense to me the way you are arguing. And I don't get whats your problem in life.
And the funny side of all this is, you are saying that I am confused.
My final comment has to be - please just heed the directive in the link I gave above. The word 'abstract' shouldn't be used within a million miles of an interface. Even if it's technically possible to do so, the application of the term in interface conditions is as useful as last year's snow.
Hahaha you are impossible. Get some life dude.
just stumbled upon the tutorials provided on the Sun website here is the link "http://java.sun.com/docs/books/tutorial/native1.1/concepts/index.html"
after downloading the tutorial and extracing it, I followed the following lnks:
Index.html --> Learning the Java Language --> Interfaces and Packages --> Creating and Using Interfaces
On this page, there is a line just below the definition of Interface which states "an interface is simply a list of unimplemented, and therefore abstract, methods."
Just another reference proving that, Interface has abstract methods and its not dangerous to use the term abstract while explaining interfaces.
@Krakatoa:
One thing I noted though, have not found any statement by java authors suggesting that abstract should not be used with interfaces, if you can find something, that will help.
after downloading the tutorial and extracing it, I followed the following lnks:
Index.html --> Learning the Java Language --> Interfaces and Packages --> Creating and Using Interfaces
On this page, there is a line just below the definition of Interface which states "an interface is simply a list of unimplemented, and therefore abstract, methods."
Just another reference proving that, Interface has abstract methods and its not dangerous to use the term abstract while explaining interfaces.
@Krakatoa:
One thing I noted though, have not found any statement by java authors suggesting that abstract should not be used with interfaces, if you can find something, that will help.
I don't really want to open this up personally, since I've said what I needed to say already. See my comment above (21631870) for an answer to the last part of your post.
For what it's worth, the use of abstract with interfaces is incorrect and I believe a late oversight by the authors, who realised that whilst it maybe is technically possible to use it in an interface, the term is "doubly-redundant" when used like that, and, as such, is a confusion, since it is a term which has a closer relationship with abstract classes, which of course really do warrant the term. But let's leave it at that, can we?
For what it's worth, the use of abstract with interfaces is incorrect and I believe a late oversight by the authors, who realised that whilst it maybe is technically possible to use it in an interface, the term is "doubly-redundant" when used like that, and, as such, is a confusion, since it is a term which has a closer relationship with abstract classes, which of course really do warrant the term. But let's leave it at that, can we?
Ok we can leave it out here, if you want, but I have gone through all the links and did not find any conclusive proposition denying one to use the term abstract with Interfaces, and secondly if the authors realized that late, I feel they should have corrected that in the newest of tutorials for Jdk 6.0. but they haven't leading to my belief that what I said was absolutely correct and acceptable. And if they think its not good practice to do so, Show me a valid link, I have gone through the link you provided in earlier comment, but there is no sufficient proof of that, those are just your comments in there.
Well, errr ...
"9.1.1.1 abstract Interfaces
Every interface is implicitly abstract. This modifier is obsolete and should not be used in new programs."
from ( as I said) :
http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html
(But I don't know who they are ... Sun or somesuch)
"9.1.1.1 abstract Interfaces
Every interface is implicitly abstract. This modifier is obsolete and should not be used in new programs."
from ( as I said) :
http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html
(But I don't know who they are ... Sun or somesuch)
By the way - you are starting to get on my nerves.
Unsubscribing = running away, defeated, terrorised, afraid and dejected.
*Shrugs*
Well you started it, you got on my nerves the very time you said, I was wrong, when I was not. And the link you gave me says "abstract" modifier should not be used (i.e. you need not say abstract explicitly when declaring a method in an interface), but its not written, that abstract should not be used conceptually. You mis-interpreted it, not me.
Well you started it, you got on my nerves the very time you said, I was wrong, when I was not. And the link you gave me says "abstract" modifier should not be used (i.e. you need not say abstract explicitly when declaring a method in an interface), but its not written, that abstract should not be used conceptually. You mis-interpreted it, not me.
The point with the interfaces and abstract classes is that with interfaces you're simulating multiple inheritance, such a weird thing!