If you have an interface (Position) with 3 methods (x(), y() and z()) and also have an abstract class, lets call it Shape.
Shape implements Position and only gives code to x() and y(). Does the compiler implicitly guess that z() is an abstract method?
Yes. So long as Shape is abstract it is not required to implement all methods of Position. That will be required of any concrete class.
The java compiler adds public and abstract keywords before the interface method and public, static and final keywords before data members.
yes, because you wont be able to instantiate the abstract class (Shape), compiler knows the z() will be implemented by some other child class (of Shape).
Abstract classes need not implement all methods. That's the responsibility of their concrete class/implementations. In this case, yes z() will be treated as abstract method of Shape.
every non-abstract class will have to provide implementation for all of the methods defined in any of it's abstract superclasses or interfaces. Compiler is clever enough to check the whole hierarchy of classes to determine that you forgot to implement something that your class claims to provide implementation for.
Related
Abstract class means, it has both abtract methods and concrete methods but even if it has only concrete methods, it is just look like a normal methods only right.
And why we are declaring the class as the abstract without any abtract methods?
On some cases, you do want to have some shared logic/fields/methods between several classes, but you do not want the base class to be instanciated by itself, only the extending classeses.
For such use-cases, abstract class, even without any abstract methods, can do the trick
It could be a base class for implementing some interfaces: all methods are concrete, but not all methods of interfaces are implemented.
An abstract class can have both abstract and non abstract methods. What is the point of having non abstract methods in the abstract class if a new object of the abstract class can't be created?
I know you can override the non-abstract method in a child class and then use it through the object of the child class. But if you are doing that, what is the need of having the non-abstract method with an implementation in the first place?
Think more or google more.
If your child classes have the common functionality then why you will override the method in every class? you can use the base class(which is abstract in this case) method.There comes the need of non-abtract(concrete as they called mostly) methods.
while having abstract method there(as you know already i think), we can override according to our requirement.
If you need all methods should be override in every child classes according to their requirement, then you can go for Interface.
Simple answer: Reuse and maintainability.
Suppose there are 4 concrete classes extending your abstract class which are all going to share some behaviors.
In this case it is better to implement the method in abstract class rather than defining it separately in all your concrete classes.
Concrete subclasses can use methods in the abstract superclass. So all shared functionality between subclasses can go into the base abstract class.
Code reusage. If you don't override non-abstract methods in your inheriting class(es) you inherit them from the abstract class.
To instead have them in the subclass violates the principle of DRY (don't repeat yourself): if all the subclasses have the same function, why write it repeatedly in every class?
As you know, in a java interface, all methods have to be defined as abstract. But when I define a method as not typing abstract, the compiler says it is okay. I know that an abstract method must not have a body. Does a method somewhere in an interface necessarily have a name abstract or not? : What i mean is, what is the difference between:
public interface blabla {
public void aMethod();
//or
public abstract void aMethod();
}
No, marking an interface method as abstract has no meaning and is never required.
All interface methods are implicitly abstract (and public too btw).
From the JLS:
Every method declaration in the body of an interface is implicitly abstract, so its body is always represented by a semicolon, not a block.
Every method declaration in the body of an interface is implicitly public.
For compatibility with older versions of the Java platform, it is permitted but discouraged, as a matter of style, to redundantly specify the abstract modifier for methods declared in interfaces.
It is permitted, but strongly discouraged as a matter of style, to redundantly specify the public modifier for interface methods.
Related question (+ answer with a historical reference to a statement saying that abstract was once required for interface methods):
Java abstract interface
See the sample example below
interface xyz
{
void methodA();
}
Save this to xyz.java
Now compile this using javac tool
and then use the command given belo
javap xyz
the output would be
Compiled from "xyz.java"
interface xyz {
public abstract void methodA();
}
That means when you compile an interface, compiler makes its signature to public and abstract by default.
So it is not necessary to use abstract keyword for any method of interface.
I don't know that they have to be defined as abstract. Probably because they don't. See Oracle's tutorial.
you don't need to specify abstract (default) because within an interface it does not make sense as all the method of the interface needs to be implemented
All methods in an interface are abstract by definition.
You can't create an object out of an interface (e.g., using Interface i = new Interface();) so there's no difference between marking a method as abstract or not.
Any class that implements the interface needs to decide whether to implement it or to let a subclass do it. So as far as the interface is concerned, all methods are abstract by default.
An abstract method provides no implementation. A class which has an abstract method is necessarily abstract, which means that you cannot create instances of this class. To create an instance of that class, you need to subclass and provide non-abstract overwrites for the abstract methods.
An interface never provides an implementation of its methods and it cannot be instantiated. Therefore every method of an interface is per definition abstract. You do not need to provide the keyword abstract when declaring a method in an interface. And by convention the keyword abstract is not used within an interface.
The methods of an interface don't have to be explicitly defined as abstract because they are implicitly abstract and public as defined in the Java Language Specification §9.4. A redundant declaration is perfectly legal though.
If you forgot to put abstract keyword before interface method, Java will implicitly put public abstract keyword before it. Because all interface methods must be abstract.
Does the class need to have the abstract keyword before it?
Or Does it need to have unimplemented (abstract) methods?
Can any normal class be extended?
Yes, all methods which are not final (static is also a bit different form the rest), can be overridden, unless the class itself is declared final. Abstract methods are only used if you do not provide any implementation in the base class.
Can any normal class be extended?
Yes :) Unless it has the final modifier.
No it doesn't need to have the word abstract, the word abstract just wont allow you to create an instance of that class directly, if you use the word abstract you can only create an instance of the classes that extend that abstract class.
AbstractClass abs = new ChildClass();
Yes you can extend a class without it needing to be defined as abstract. What this means is that you will be overriding methods. For example, you might make a class
DifferentString extends String
then,
public String toString()
{
return "Something different";
}
This will mean you can change the original behaviour of the parent class.
Reference:
http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html
As others have also said, yes - but it is good practice to avoid doing so if you can possibly help it, because you can end up with what is known as the fragile base class problem more easily.
Yes, but if the class is marked as final, it can't be extended.
class Foo {
//some code here
}
class Boo extends Foo {
}
There are some concept confusions here. Unimplemented methods reside in an interface, and you can implement that interface.
You can extend any class as long as its not final.
Edit: What I meant to say that it is preferable to put Unimplemented methods in interfaces as well. Sorry for the poor wording. Abstract classes can have unimplemented methods as well, though you will end up with a complex and rigid hierarchy.
.
I have read somewhere that we cannot initialize an interface, for example:
interface MyInterface{};
And the following code is definitely illegal:
MyInterface m = new MyInterface();
And as I remember the text I have read said: that because the new keyword is used to allocate memory for class members; so in case of interface, we only have abstract functions, so there is nothing to be allocated in an interface; therefore, initializing an interface is prohibited.
OK, that makes sense to me.
But in case of abstract class, we are allowed to declare and define abstract functions, non-abstract function, as well as normal variables;so why we also are not allowed to initialize an abstract class? And because of that, I was wondering when and how variables in an abstract class, if any, are allocated memory?
No object is ever an instance of "just" an abstract class - it's always an instance of a concrete class. Otherwise you could call the abstract methods... and there'd be no implementation to be called.
The variables in an abstract class are allocated the same way as the variables of any other class which happens to be a superclass of the actual class being initialized - they live "with" the variables from the other classes in the hierarchy, basically.
EDIT: To clarify, this is a conceptual limitation as much as an implementation one. An abstract class usually contains abstract methods, which is the reason for making it abstract. The point of abstract methods is to allow the caller to have compile-time checking that the method will be there, even though the abstract class doesn't provide the implementation. The VM ensures that there is an implementation by preventing instantiation of "just" abstract classes.
Now abstract classes can also be used to prevent instantiation even if there aren't any abstract methods - basically the fundamental point of an abstract class is that it's one which can't be directly instantiated; only concrete subclasses can be instantiated.
When you say "initialize" you really mean two separate things: Allocation and construction. Allocation is the process of obtaining memory for the object; construction is the process of putting bringing the object itself to life.
As you observe rightly, your interface class requires no memory. But that's not the point. An abstract class cannot be constructed because it is... well, abstract. There is no object of abstract type. And interfaces are abstract.
Think of a Mercedes being an abstract Car. You can buy a Mercedes, but you cannot buy an abstract car - it doesn't make semantic sense. Any car you could conceivably have has to be of a concrete type.
Edit: It might be useful to contemplate why a class may be abstract:
Because it is declared abstract class. This makes it abstract flat-out by decree, no reason given.
Because it has abstract member functions: The member function isn't implemented, and a concrete, derived class must provide the implementation.
Because it is declared interface: This is morally equivalent to "all member functions are abstract, and there are no member objects". (Having a separate keyword for this allows interfaces to circumvent the limitations of single inheritance.)
That's the point of an abstract class: to be the base class for other classes. It is specifically designed to not be instantiated.
Most abstract classes has abstract methods, which do not have implementations. How would you call such a method if you instantiated the abstract class itself?
When you use new to create a new instance of a subclass of an abstract class, the memory required for the base abstract class will be allocated then as well.
An abstract class is a class which is not finished yet and generally has abstract members(although it is not obligatory). So you cannot instantiate an abstract class. This is defined by the language.
An abstract class is a class that is declared abstract—it may or may
not include abstract methods. Abstract classes cannot be instantiated,
but they can be subclassed.
If a class includes abstract methods, the class itself must be
declared abstract.
http://download.oracle.com/javase/tutorial/java/IandI/abstract.html
abstract classes are not full. they have abstract methods, which are not implemented.
what will happen if you try to invoke one of them?
abstract class' variables are located on memory by the concrete instantiated class.
The variables in an abstract class are allocated when the new keyword is used on a class that extends the abstract class.
So if you don't have a class extending your abstract class they never get allocated.
When you instantiate a class, you're allocating memory for several aspects of the class, including an area for methods (it's significantly more involved than this). Abstract classes do not have definitions for some methods, so we cannot put pointers to actual methods.
Abstract classes contain -- at least partially -- methods without definitions. You can't call those, because there's no code to run.
Maybe an illustration with some code could be useful.
abstract class AC{
abstract public void m();
}
class Main{
public static void main(String[] a){
AC obj = new AC();
obj.m(); /* Nothing to execute. */
}
}
So this behavior must be forbidden.
By the way, even if your interface is empty, you would have to provide an empty implementation:
Serializable x = new Serializable(){};
The empty curly braces will be needed for an abstract class too. I can't think of encountering a need for these constructs though.