It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
A common argument is that Polymorphism only applies to interfaces and not abstract classes.
Is the relationship of as Abstract parent class to a concrete class that extends it considered a polymorphism?
List list = new Arraylist()// Polymorphism as List is an interface
AbstractClass parent = new Child(); // Is this also considered polymorphic?
Common argument is Polymorphism only applies to Code to interface and Not abstract classes.
That "argument" is factually incorrect.
Polymorphism works just fine in Java whether you are using interfaces, abstract classes or non-abstract classes. (There are questions about which is best for long term maintainability, but that is a different topic.)
I'd be curious where you found that "argument". Can you provide a URL?
Yes. That is polymorphic.......
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
What kind of classes can be extended by interfaces? What are the rules?
All the Java programmers I know think that interfaces cannot extend classes but
java.util.concurrent.ExecutorService:
public interface ExecutorService extends Executor { //...
java.util.concurrent.Executor:
public class Executors { //...
So, it looks like some interfaces can extend some classes. What are the rules? I only noticed that java.util.concurrent.Executor has static members only and a private constructor. Can somebody explain the rules and the purpose? Thanks.
Interface can only extend another interface and not a class.
Since interfaces have no actual implementation of any logic (this is not possible in Java), there is no fear of possible collisions if some interfaces have the same method signatures.
Executor is an interface and not a class, unless Javadoc is mistaken or I misread your post. So there is not any problem with another interface extend it.
Every single method declared in an interface will have to be implemented in the sub-classes.
A class can implement multiple interfaces and it can not be private.
A class that implements an interface must provide an implementation of all the method of that
interface. as far as doing it the other way around as
#darijan says "Interface can only extend another interface and not a class......."
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
ClassLoader is an abstract class, even though it doesn't have any abstract methods. Why is that so? Are there any other abstract classes without abstract methods?
A class with abstract methods has to be abstract. However, an abstract class doesn't have to have abstract methods.
Generally, a class should be abstract whenever it doesn't make sense conceptually for instances of that class to exist. Having incomplete implementation is one example of this (and it happens to be enforced by the compiler), but it's not the only example.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Why must implement always be written after extend in a class declaration? For example:
public class Register extends ActionSupport implements ModelDriven
Why can it not be:
public class Register implements ModelDriven extends ActionSupport
The latter produces a compile-time error.
When the Java compiler turns a class into bytecode, it must first look to a parent class. That is because the underlying implementation of classes is to point to the bytecode of the parent class - which holds the relevant methods and fields. Then it adds in pointers to the code of the child class functions - some of which are mandated by the 'implements' keyword.
Because the parent class must be compilable, it is easier if the compiler knows up front what that class is. Further, you can extend only one class but implement any number of interfaces. The compilation time climbs if the extends keyword can be intermingled amongst any number of implements instructions. Compilers want to fail as fast as possible to decrease dev time, so this choice is logical. Further, it helps you think clearly about the class for the same reason.
Probably to make the compiler's job easier. It's just a convention. There isn't any advantage to being able to rearrange these things.
It's like asking why Java functions aren't written in pre-order notation like public int (int a, int b)add{ return a+b; }.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
public abstract class Two extends One
{
}
Class One is defined as
public abstract class One
{
}
Yes, and you cannot instantiate it either, of course.
Yes, you can.
If you extend a class with an abstract class and do not define or provide the implementation for the base class abstract methods then the child class extending it would automatically become abstract.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
There is a public final class Objects in Java 7 that extendes the java.lang.Object base class.
Will this by default be the base class like or do we need to call the method on "Objects" class and call the corresponding methods?
No. Nothing changes. The Objects class is simply an utility class. It has only static methods, it's in the util package, and does what ObjectUtils from commons-lang is doing.
Objects is final and it extends Object giving you null safe utilities.