public abstract class A {
abstract void polo();
}
class B extends A {
}
My doubt is if I give abstract keyword in class B means it wont shows anything
abstract class B extends A {
}
Why its not showing the message here to implement methods in class A - this is my doubt.
If I didn't give abstract keyword means class B indicates like this
The type B must implement the inherited abstract method A.polo()
What's wrong with that one. Can abstract class extend another abstract class or not.
If a non-abstract class extends an abstract class, it must implement all abstract methods, in your case class B must implement polo()
If you make class B abstract, then you don't have to. But in this case you can't create an instance of B and the classes that extends B should implement polo
You can extend an abstract class, but you must decide what the new one will do about the abstract methods. You can choose to implement all those methods, so the abstract keyword won't be required. You can also implement some or none of the methods, but you must mark the class as abstract.
Depending of the business logic, you may put the abstract methods into an Interface that required classes will implement.
if B is abstract
not mandatory to implement the method
but you can implement the method or left implementation for child class
but if B is not abstractit is mandatory you implement the abstract method
One handy trick I use in this situation is to make class B non abstract to start with. I then use the IDE to generate the over-rides for all the abstract methods and then afterwards I make class B abstract and then go through the overridden methods and decide for each one whether to implement them or leave them abstract at this level too.
Related
I am having an interface called I. This interface is implemented by an abstract class AClazz.
AClazz implements I
Now this abstract class is extended by several concrete classes.
ConcreteClazz extends AClazz
AnotherConcreteClazz extends AClazz
Now when I add a new method contract to the interface I why does eclipse and hence Java language complain about a missing implementation inside the concrete classes (ConcreteClazz and AnotherConcreteClazz) and not inside the abstract class AClazz?
If AClazz was a concrete class (& not abstract) and the concrete classes extended from the non abstract AClazz will Java complain about missing implementation inside concrete classes again?
So say your interface I has a method m:
public interface I {
public void m (int someParameter);
}
Now AClazz implements I, and ConcreteClazz extends AClazz. That means that ConcreteClazz also implements I, whether or not you say so explicitly in the class declaration of ConcreteClazz. That means you can use a ConcreteClazz object anywhere an I is expected. So say somewhere, in some other class, you have a method
void takeSomeAction(Something x, I y) {
....
y.m (x.getSomeProperty()); // call the interface method
....
}
You can call it with a ConcreteClazz object:
ConcreteClazz z = new ConcreteClazz(...);
Something st;
foo.takeSomeAction(st, z);
You're giving takeSomeAction a ConcreteClazz to use as its I parameter. Then takeSomeAction will call the m method. How can this work unless you've provided an implementation for m, somewhere?
That's why you need to implement m, either in AClazz or ConcreteClazz. You could implement it in AClazz, if that's the right thing to do, and then you don't need to provide another implementation in ConcreteClazz. But if you don't implement it in AClazz, it won't cause any errors, since, at runtime, you can't actually have an object of type AClazz. But since you can have objects of type ConcreteClazz, that means that somewhere, for ConcreteClazz, there has to be an implementation of m.
An Abstract class means, this class contains abstract methods (i.e. no implementation, only definition of method), the classes that are extending it must implement the unimplemented methods.
Since an Interface contains 100% pure public abstract methods, which must be implemented by the classes that are implementing them unless it's marked as abstract. Again follow the above rule.
An abstract class remains abstract no matter how many new abstract methods you add to it. So compiler does not complain when you add a new method in your I interface which is implemented by your abstract class.
A concrete class cannot have any abstract methods, as your subclasses are extending your abstract class and that class does not implement the newly added method to the interface, hence the compiler complains. Because newly added abstract method is inherited in all your child classes and a concrete class cannot have an abstract method.
I have two questions really. I'm trying to get a handle on how inheritance works.
If I have an abstract class to inherit from, and it has a method that is not labelled abstract does this method still need to be implemented in the subclass?
If I have a subclass that is inheriting from another subclass, which is then inheriting from an abstract class, does the lowest subclass need to implement the methods in the abstract class? Or because the methods have been implemented in the middle subclass, they don't need to be implemented again?
Thank you!
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.
An abstract method is a method that is declared without an implementation (without braces, and followed by a semicolon), like this:
abstract void moveTo(double deltaX, double deltaY);
If a class includes abstract methods, the class itself must be declared abstract, as in:
public abstract class GraphicObject {
// declare fields
// declare non-abstract methods
abstract void draw();
}
When an abstract class is subclassed, the subclass usually provides implementations for all of the abstract methods in its parent class. However, if it does not, the subclass must also be declared abstract
If the method is not abstract it has been implemented already, when you subclass the abstract class you inherit the method implementation, re-implementing it would be overriding it. If the method was declared abstract you must implement or get compile-time error if the subclass is also not declared abstract.
If you are inheriting from a class A extends AbstractClass that is not abstract then A must have implemented any abstract methods or again compileerror. If it hasn't implemented any abstract classes then A must also be abstract and responsibility of implementing the abstract methods fall on subclassers of A. Any sublcassers that do not implement the method must also be declared abstract untill finally a subclass implements it.
What is difference between abstract class and non abstract class when extending derived classes? Both class I didn't use the method overriding and abstract methods (i.e. abstract class). Just I inherited the properties. What and why did prefer the class?
Ex:
Code 1:
abstract class a {
protected int empnno;
protected String empname;
}
class b extends a {
...
}
Code 2:
class a {
protected int empnno;
protected String empname;
}
class b extends a {
...
}
what is difference to extend abstract class and non abstract class?
Abstract classes may have abstract methods. Abstract methods are methods without implementations and these must be implemented by your subclass (unless you make your subclass abstract too).
Since your a class have no abstract methods, there is no difference what so ever from a subclass-perspective. (The only difference is that if a is abstract it may no longer be instantiated as is. It may only be instantiated in terms of subclasses.)
Suppose there is a class B, and class A, where A extends be. The following are the possible scenarios:
1. B is abstract
1.1. B doesn't have abstract methods
1.1.1. A is abstract
1.1.1.1. You don't want to instantiate A. Everything is fine.
1.1.1.2. You want to instantiate A. That's not possible, you can't create abstract objects
1.1.2. A is not abstract. Everything is fine
1.2. B has at least an abstract method
1.2.1. A is abstract
1.2.1.1. You don't want to instantiate A. Everything is fine.
1.2.1.2. You want to instantiate A. That's not possible, you can't create abstract objects
1.2.2. A is not abstract
1.2.2.1. A doesn't implement all the abstract methods. You can't run your project until you change this
1.2.2.2. A implements all the abstract methods. Everything is fine.
2. B is not abstract
2.1. A is abstract
2.1.1. You want to instantiate A. Error.
2.1.2. You don't want to instantiate A. No problem
2.2. A is not abstract. No problem.
To have a better understanding, we can compare Abstract Classes with Interfaces, the main differences are:
While abstract classes may contain fields/properties and concrete
methods, interfaces may contain only abstract methods (method
signatures).
One class can implement several interfaces, whereas it can extend just one class, abstract or not.
Therefore, when you create a subclass extended an abstract class, you need to implement the abstract method that was in the abstract class(if any), otherwise, the subclass would be still an abstract class -- which cannot be instantiated!!
Also, you can use interfaces instead of abstract classes if you only want to declare some methods signatures.
Actually they are the same, but you cannot instanciate Abstract classes. So if you want nobody tries to instanciate your class, you would like to make it Abstract.
An abstract class will contain abstract methods that do not have an implementation.
When you extend this class, sometimes you may decide only to provide implementations for some of those abstract methods. In this case you've extended an abstract class and yet the subclass is still abstract.
If you implement all the abstract methods, your subclass is typically not abstract (although there's nothing stopping you from declaring it as such, AFAIK).
Can I define an abstract class without adding an abstract method?
Of course.
Declaring a class abstract only means that you don't allow it to be instantiated on its own.
Declaring a method abstract means that subclasses have to provide an implementation for that method.
The two are separate concepts, though obviously you can't have an abstract method in a non-abstract class. You can even have abstract classes with final methods but never the other way around.
Yes you can. The abstract class used in java signifies that you can't create an object of the class. And an abstract method the subclasses have to provide an implementation for that method.
So you can easily define an abstract class without any abstract method.
As for Example :
public abstract class AbstractClass{
public String nonAbstractMethodOne(String param1,String param2){
String param = param1 + param2;
return param;
}
public static void nonAbstractMethodTwo(String param){
System.out.println("Value of param is "+param);
}
}
This is fine.
Yes you can do it. Why don't you just try doing that?
YES You can create abstract class with out any abstract method the best example of abstract class without abstract method is HttpServlet
Abstract Method is a method which have no body, If you declared at least one method into the class, the class must be declared as an abstract its mandatory BUT if you declared the abstract class its not mandatory to declared the abstract method inside the class.
You cannot create objects of abstract class, which means that it cannot be instantiated.
Yes we can have an abstract class without Abstract Methods as both are independent concepts. Declaring a class abstract means that it can not be instantiated on its own and can only be sub classed. Declaring a method abstract means that Method will be defined in the subclass.
Yes, you can declare a class you cannot instantiate by itself with only methods that already have implementations. This would be useful if you wanted to add abstract methods in the future, or if you did not want the class to be directly instantiated even though it has no abstract properties.
yes, we can declare an abstract class without any abstract method. the purpose of declaring a class as abstract is not to instantiate the class.
so two cases
1) abstract class with abstract methods.
these type of classes, we must inherit a class from this abstract class and must override the abstract methods in our class,
ex: GenricServlet class
2) abstract class without abstract methods.
these type of classes, we must inherit a class from this abstract class,
ex: HttpServlet class
purpose of doing is although you if you don't implement your logic in child class you can get the parent logic
please check the HttpServlet source code
You can, the question in my mind is more should you. Right from the beginning, I'll say that there is no hard and fast answer. Do the right thing for your current situation.
To me inheritance implies an 'is-a' relationship. Imagine a dog class, which can be extended by more specialized sub types (Alsatian, Poodle, etc). In this case making the dog class abstract may be the right thing to do since sub-types are dogs. Now let's imagine that dogs need a collar. In this case inheritance doesn't make sense: it's nonsense to have a 'is-a' relationship between dogs and collars. This is definitely a 'has-a' relationship, collar is a collaborating object. Making collar abstract just so that dogs can have one doesn't make sense.
I often find that abstract classes with no abstract methods are really expressing a 'has-a' relationship. In these cases I usually find that the code can be better factored without using inheritance. I also find that abstract classes with no abstract method are often a code smell and at the very least should lead to questions being raised in a code review.
Again, this is entirely subjective. There may well be situations when an abstract class with no abstract methods makes sense, it's entirely up to interpretation and justification. Make the best decision for whatever you're working on.
yes you can do that.
declaring class abstract means that class will not be instantiated by any other class.
and there should be at least one abstract method inside that and meaning of that you can declare abstract method in that class if you are not declaring method than its ok.
example:
public abstract class abs {
protected int cx = 0, cy = 0;
public void p() {
System.out.print("hello");
}
}
this will work for sure.
Yes you can. Sometimes you may get asked this question that what is the purpose doing this?
The answer is: sometimes we have to restrict the class from instantiating by its own. In that case, we want user to extend our Abstract class and instantiate child class
Actually there is no mean if an abstract class doesnt have any abstract method . An abstract class is like a father. This father have some properties and behaviors,when you as a child want to be a child of the father, father says the child(you)that must be this way, its our MOTO, and if you don`t want to do, you are not my child.
Yes, you can define an abstract class without an abstract method. However, if there is no method inside you might better go with an interface
I have class B, which inherits from class A. The superclass A is abstract, containing one abstract method. I don't want to implement the abstract method in class B, therefore I need to declare class B as abstract as well. Declaring class B abstract, two things are working for me (the programs compile and run correctly):
1.) I don't declare any abstract methods in class B, even thought the class is abstract. This works, I assume, because the class inherits the abstract method of class A, and this is enough for the class to be declared as abstract: we don't need any other abstract methods directly declared in the class.
2.) I do declare the same abstract method in class B as it is declared in class A. This is some kind of overriding (?), not in the same sense as overriding in java (using the same header, but providing different implementation), here I just use again the same header of the method.
Both things are working, and I am not sure whether they are both Ok, and whether some of them is preferred (more correct) that the other. Are the two ways the same (do they mean the same to Java)?
Here I give some example classes, so that what I mean is more clear for you:
Case 1.):
public abstract class A {
public abstract String giveSum();
}
public abstract class B extends A {
}
Case 2.):
public abstract class A {
public abstract String giveSum();
}
public abstract class B extends A {
public abstract String giveSum();
}
Regards
In Java, the abstract class annotation indicates that the class cannot be directly instantiated. A class could be declared abstract simply because it should never be instantiated (perhaps it contains only static methods), or because its subclasses should be instantiated instead.
It is not a requirement that abstract classes contain abstract methods (the inverse is true: a class containing one or more abstract methods must be abstract.)
The question of whether you should duplicate the abstract method definition might be perceived as a style question - but I would be hard pressed to come up with an argument in favor of duplicating the definition (the only argument I can come up with is in the case where the class hierarchy might change the semantics or use of the method, and thus you'd like to provide an additional javadoc in class B.)
The primary argument against re-definition of the abstract method is that duplicate code is bad - it makes refactoring more cumbersome and such (all the classic "don't duplicate code" arguments apply.)
They are functionally equal, but the first one is preferred because it's shorter and isn't weird.
Go with #1. Rewriting the method declaration in the child class is confusing. And you actually don't need any abstract methods in an abstract class, regardless of whether the parent is abstract or not.
So, the question is: Which is preferred when sub classing an abstract class in java and don't want to provide implementation?
a) mark subclass as abstract too
b) mark subclass as abstract too AND re-write the method signature marked as abstract?
I would go for the first one:
a) Mark subclass as abstract too.
The former has already the abstract method declaration, there is no point in repeating it.
You are right, the two cases are equivalent. Case 1) is more simple, case 2) is code duplication - avoid it. But there may be one reason to do so:
If the method in class A does not return String but lets say C, class B may override it (since Java 5) with a more specific return type, lets say D (class extends C):
public abstract class A {
public abstract C giveSum();
}
public abstract class B extends A {
public abstract D giveSum();
}
public class C {
...
}
public class D extends C {
...
}