Following code is compiling absolutely fine.
To my understanding it should not be because Class C implementing interface I
as abstract class fails to compile as well.
interface I {
public String toString();
}
class C implements I {
}
Abstract class is not compiling
abstract class MyAbstractClass {
public abstract String toString();
}
public class MyClass extends MyAbstractClass {
}
Please help me understand this behavior why abstract is not compiling and interface does ?
Every class implicitly extends java.lang.Object, and java.lang.Object implements the toString() method. The interface's contract is satisfied by that implementation, thus removing the need for your class to provide its own implementation of toString().
The reason compilation fails for the abstract class is because you explicitly define the toString() method as abstract, thereby signaling that concrete extending classes are forced to provide their own implementation.
Related
I am just confused about abstract class concept. Please clear my doubt. Definition of Abstract class says we can not create object of such class, then what we called like A a = new A() { }. Example is below:
public abstract class AbstractTest {
public abstract void onClick();
public void testClick() {
}
}
public class A {
AbstractTest test = new AbstractTest() {
#Override
public void onClick() {
}
};
}
Then test is a object or what?
test is an object of an anonymous concrete sub-class of AbstractTest (note that it implements all the abstract methods of AbstractTest), which is why this sub-class can be instantiated.
On the other hand,
AbstractTest test = new AbstractTest();
wouldn't pass compilation, since that would be an attempt to instantiate an abstract class.
You are mixing up object and reference.
AbstractTest test = new AbstractTest() {
#Override
public void onClick() {
}
};
test here is a reference to a anonymous class that extends AbstractTest, the above code is like saying:
class MyClass extends AbstractTest {
#Override
public void onClick() {
}
}
AbstractTest test = new MyClass(); // test is a reference to a MyClass object
Abstract Class in my opinion needs to be explained together with Interface.
Interface allows you to specify operations that are supported/allowed on objects with that interface. More specifically Objects are instances of a Class which implements that Interface. Defining an interface allows you to describe a group of different classes of objects so that other objects can interact with them in the same manner.
Abstract Class is one step between interface and a Class (loosely speaking). Abstract Class allows you to specify operations that are supported by classes that extend it, but it also allows you to implement (some of) those operations. This way you can implement common methods for a group of classes in that abstract class. Other methods in the abstract class that are not implemented (aka abstract methods) need to be implemented by the class that extends it. The fact that you didn't implement all methods on an Abstract class naturally means you can't instantiate it (create an object of such class). There are other useful implementations for Abstract classes (i.e. callbacks).
In your example what you see there is that you are not really trying to just create an object that Abstract class you are also providing implementation of abstract method onClick();
That is the only way you can "create an instance of the abstract class" - technically speaking you are creating an instance of an Anonymous class (that is extending your abstract class) for which you provide implementation of inherited abstract methods.
I have a concrete class which extends an abstract class, which in turn extends an abstract class. This top class implements an interface. Can I implement the interface method in the top abstract class, so that the concrete sub-class does not have to?
Also, if the interface method takes an Object type as it's parameter, can I have the implementation in the top abstract class take another type (which seems right to me), or would I have to use exactly the same method signature?
Can I implement the interface method in the top abstract class, so that the concrete sub-class does not have to?
Yes
Also, if the interface method takes an Object type as it's parameter, can I have the implementation in the top abstract class take another type (which seems right to me), or would I have to use exactly the same method signature?
It has to be the same signature. However, you can trick with generics, if you want to and if you explain your plan in more detail.
for your fist quetion
Can I implement the interface method in the top abstract class, so that the concrete sub-class does not have to?
you can and you should if its a common feature for all the subclasses.
below is the example for the same
interface X{
void show();
}
abstract class A implements X{
public void show(){
System.out.println("show");
}
}
abstract class B extends A{
}
class C extends B{
}
for your second question
No , signature must be same always.
so below program illustares it
interface X{
void print(Object obj);
}
abstract class A implements X{
#Override
public void print(Object obj) {
System.out.println("print");
}
}
below program wont compile if you change type in subclass
interface X{
void print(Object obj);
}
abstract class A implements X{
#Override
public void print(A obj) {
System.out.println("print");
}
}
I understand how to use the Comparable<T> interface, but in this specific example, I'm wondering if there is a way to require the inheriting Class from an Abstract Class (which implements the Comparable<T> interface) to be Comparable against itself.
Let me reiterate, there is an Abstract Class that implements the Comparable Interface:
public abstract class MyAbstractClass implements Comparable<MyAbstractClass>
And a Class which inherits from this Abstract Class:
public class MyClass extends MyAbstractClass
Typically with this setup, the following method is required to satisfy the Comparable Interface:
public int compareTo(MyAbstractClass otherAbstractObject)
This requires me to make the following cast:
public int compareTo(MyAbstractClass otherAbstractObject)
{
MyClass otherObject = (MyClass) otherAbstractObject;
// Comparison...
return result;
}
Given the fact that this cast could easily fail by trying to use a different child of MyAbstractClass, I would like to be able to define my Abstract Class to accept the following method:
public int compareTo(MyClass otherMyObject)
{
// Comparison...
return result;
}
And ideas on how to accomplish this? Or is it simply not possible?
You can define MyAbstractClass using generics as follows:
public abstract class MyAbstractClass<T extends MyAbstractClass<T>>
implements Comparable<T> {
Then you can define subclasses such as
public class MyClass extends MyAbstractClass<MyClass>
which allow you to define the compareTo method like this:
public int compareTo(MyClass otherMyClass)
However, that doesn't prevent anyone from writing a subclass that doesn't conform to the pattern:
public class SneakyClass extends MyAbstractClass<MyClass>
which would also define the compareTo method similarly:
public int compareTo(MyClass otherMyClass)
Note: There's nothing that can force the generic type parameter of a class to equal the class on which it's defined; the best you can do is to enforce an upper bound on the abstract class, to at least force it to be some kind of MyAbstractClass.
Below is the code snippet:
public abstract class MyAbstractClass {
public abstract void a();
public abstract void b();
}
public class Foo extends MyAbstractClass {
public void a() {
System.out.println("hello");
}
public void b(){
System.out.println("bye");
}
}
public class Bar extends MyAbstractClass {
public void a() {
System.out.println("hello");
}
public void delta() {
System.out.println("gamma");
}
}
There are couple of questions that I have:
Q-1 :- Should I implement ALL the methods in abstract class?
Q-2 :- Can the implementing class have its own methods?
When you extend an Interface or an Abstract class you are creating a contract of sorts with that superclass. In the contract you are saying:
"I will implement all unimplemented methods in my superclass"
If you do not, implement all the unimplemented methods, then you are breaking your contract. A way to not break your contract is make your subclass Abstract as well as a way of saying
"I have not implemented all the classes in my contract, I am going to
have my subclasses implement them".
For your class bar right now, you must implement b() or make bar an Abstract class or you are not fulfilling your contract with MyAbstractClass
The basic idea is:
Interface: None of my methods are implemented. A subclass must implement all my methods in order to implement me. (Note: I believe default interfaces have been added to Java 8 which may change this a bit)
Example:
public interface myInterface
{
//My subclasses must implement this to fulfill their contract with me
public void methodA();
//My subclasses must implement this to fulfill their contract with me
public void methodB();
}
Abstract: I may implement some of my methods, but I will also leave methods as abstract so that my subclasses must implement because they can implement those classes to suit their needs better than I can.
Example:
public abstract class myAbstractClass
{
//My subclasses must implement this to fulfill their contract with me
public abstract void methodC();
public void helloWorld()
{
System.out.println("Hello World");
}
}
Abstract classes can also extend interfaces so they can implement some of their methods. But they can also leave some of the methods unimplemented so the subclass can implement them. If you leave an interface method unimplemented, there is not need to declare it abstract, it is already in the contract.
Example:
public abstract class myAbstractClass2 implement myInterface
{
#Override
public void methodA()
{
// this fulfills part of the contract with myInterface.
// my subclasses will not need to implement this unless they want to override
// my implementation.
}
//My subclasses must implement this to fulfill their contract with me
public abstract void methodD();
}
So in essence, an abstract class doesn't have as strict a contract with it's superclass because it can delegate its methods to its subclasses.
Regular Class: (I use regular to mean non-interface, and non-abstract). I must implement all unimplemented methods from all of my superclasses. These classes have a binding contract.
Example:
public class mySubClass extends myAbstractClass2
{
#Override
public void methodB()
{
//must be implemented to fulfill contract with myInterface
}
#Override
public void methodD()
{
//must be implemented to fulfill contract with myAbstractClass2
}
public void myMethod()
{
//This is a method specifically for mySubClass.
}
}
Q-1:- Should I implement all methods in abstract class?
Yes, you must implement all abstract methods.
Q-2 :- Can the implementing class have its own methods?
Yes, you can declare own (more specfic) methods.
You not only should, but have to implement all abstract methods (if the subclass is non-abstract). Otherwise an object of that subclass wouldn't know what to do if that method was called!
The only way to prevent this is if the subclass is also declared abstract, so that it cannot be instantiated in the first place.
You don't have to implement all methods of an abstract class. But you must implement all abstract methods of it.
In fact extending an abstract class has no difference then extending a normal class. It's not like implementing interfaces. Since you're extending you are creating a subclass thus you can add as many methods and attributes as you need.
Ya definately implementing class can define its own method as well and if are not implementing all the methods of your abstract class in the derived class then mark this derived class also as Abstract
but at the end of chain you have to make one concrete class which implements all the method that was not implement in abstract sub-parent
public interface I{
public void m();
}
public abstract class A1 implements I{
//No need to implement m() here - since this is abstract
}
public class B1 extends A1{
public void m(){
//This is required, since A1 did not implement m().
}
}
public abstract class A11 extends A1{
//Again No need to implement m() here - since this is abstract
public abstract void newA11Method()
}
public class B11 extends A11{
//This class needs to implement m() and newA11Method()
}
Yes, the implementing class need only implement the methods labeled as abstract in the abstract class.
Yes you must implement all the methods present in an abstract class. As the purpose of abstract class is purely to create a template for the functions whose implementation is decided by the class implementing them. So if you don't implement them, then you are breaking the concept of abstract class.
To answer your second question, yes you can create any number of your own methods irrespective of the abstract class you are extending.
Yes, When you are implementing an Interface you will have to implement all its methods. That is the purpose of defining an Interface. And yes, you can have your own methods in the class where you implement an Interface.
Yes, when you extends abstract you should give implementation for all abstract methods which are presents in abstract class. Othrewise you should make it implementation class as abtract class.
You must implement all the abstract methods you have in the abstract class. But you can directly use the concrete methods that are implemented.
For more information please refer to the :
https://www.javatpoint.com/abstract-class-in-java
Can I implement abstract methods in an abstract base class A in java?
If the answer is yes and there is an implemented abstract method in a base class A and there is a derived class B from A (B is not abstract). Does B still has to implement that base abstract method?
If I understand your question correctly, Yes.
public abstract class TopClass {
public abstract void methodA();
public abstract void methodB();
}
public abstract class ClassA extends TopClass {
#Override
public void methodA() {
// Implementation
}
}
public class ClassB extends ClassA {
#Override
public void methodB() {
// Implementation
}
}
In this example, ClassB will compile. It will use it's own implementation of methodB(), and ClassA's implementation of methodA(). You could also override methodA() in ClassB if desired.
You could have two abstract classes, X and Y, where Y extends X. In that case it could make sense for Y to implement an abstract method of X, while still being abstract. Another non-abstract class Z could extend Y. However, in your example, for A to implement its own abstract methods is a contradiction, the point of making them abstract is so it doesn't provide implementations, it just specifies what the method signatures should look like.
If you implement an abstract method it's not really abstract any more, so no.
Abstract classes can have regular methods. If you want to implement some of the methods of class A and leave rest of the methods abstract, you can do this. However, abstract methods cannot have a body, therefore if you mark a method as abstract, then it has to be implemented by a subclass, you can't implement them in the abstract class. However, you can have an abstract class without abstract methods, then subclass only needs to extend it.
Yes, you can implement abstract methods in a class which is declared as abstract. If a class is declared abstract that does not mean all its method must be abstract.
For a concrete sub class, it is not mandatory to implement the abstract methods that are already implemented by one of their super class.
No. Abstract methods are meant to be defined by the subclass(es). For more information, see Abstract Methods and Classes. However, you can define a method in the base class and have the subclass(es) override it, if required.
Yes, but it can't be abstract any more. Abstract means there is no implementation.
What you can do is:
interface I {
void meth();
}
//and
abstract class A implements I {
public void meth() {
//implementation
}
}
Or:
abstract class A {
public abstract void meth();
}
//and
abstract class B extends A {
public void meth() {
}
}
If A already has an implementation, you can override it in B (if B is concrete), because B inherits that default implementation from A.