Question

I understand that in abstract classes methods be both abstract, or not. But why can I not create an abstract method in a "normal", non-abstract class?

Thanks in advance for any explanation!

Was it helpful?

Solution

Abstract method basically says, that there is no implementation of the method and it needs to be implemented in a subclass. However if you had an abstract method in a non-abstract class, you could instantiate the class and get an object, that would have an unimplemented method, which you would be unable to call.

OTHER TIPS

Having an abstract method prevents a class from being instantiated, thus making it a de-facto abstract class. Java insists on you declaring this fact explicitly for consistency: technically, Java compiler does not need this additional mark in order to decide if a class is abstract based on the presence of abstract methods, but since you may want to make a class abstract without making any of its methods abstract, requiring the declaration on the class was the way to go.

Lets start by understanding why we need something like a abstract method. The answer is simple. I dont want my extenders to use my methods as it is, I want them to define their own behavior of a particular method. Since I use this method in other methods of my abstract class. I can provide a /**java doc**/ on the abstract class and point them to use a default behavior.

class abstract LoveTheWorld {
    private int myKindness ;
    public int defaultGiveKindness() {
        myKindness -= 5 ;
        return 5 ;
    }
    /**
    you can use the defaultGiveKindness method, and not define your own behavior
    **/
    public abstract int giveKindness() ;
}

This also tells the extender that they can extend only one class (as per java inheritance rules). Now, if you want to twist this story around, you can use interface instead of a abstract class. But it all depends on what constraints do you want your future developer to adhere to, strict or flexible. Strict will keep it tight and ensure reduced mistakes, flexible will keep it loose and free and promote innovation. The question is **what do you need*8.

You do want to call a method providing an implementation, that's the essence of programming.

Based on this idea, Java rules are:

  • You cannot instantiate an abstract class.
  • You can only instantiate a non-abstract class.

What if Java let you call a method on an instance of a non-abstract class with...no implementation since method would be abstract => no sense at all.

That's why Java and any other languages dealing with similar mechanism like C# (virtual method) prevent to declare an abstract method in a non-abstract class.

If a concrete class could have an abstract method, you would not be able to create an object from it. Imagine a Shape with a concrete method getColor() and an abstract method draw(). It's great to refer to some things in an abstract manner, so someone can tell you "render a shape!":

public void render(Shape s) { ... }

But when you use that reference to call draw(), you expect that the object referred by s knows how to do that:

s.draw();

If concrete classes were allowed to have abstract methods, you could instantiate a Shape object, but when you called the draw method, it wouldn't know what to draw! Even if it knew how to say its color, position or 1000 other things. If it's not 100% specified, it can't exist as a working objects.

So Java requires that such classes be marked as abstract. Then you won't be able to use them to create objects, since they don't know how to concretely do 100% of the things that you expect from the object. You can only use abstract classes to refer to them. You can be sure now that only classes that have all their methods implemented will be used to create objects, and they will probably have names that seem less abstract too:

Shape shape = new Rectangle();
render(shape);

Now you can say "render the shape" and you program, using reference to the rectangle, will know how to draw() it.

Because having an abstract method makes it an abstract class. The reasoning is circular.

abstract methods are meant for leaving the implementation to the child classes.If the normal class contains abstract method,then one can creating the object for that class and may call the abstract method just like normal method.Then the problem will occur.That's is the reason abstract methods should be in abstract class (so that one cannot create the object for the abstract class)or interfaces only.

The simple answer is if the class is not abstract(concrete class) you could be able to instantiate that class and call any method of that class .but let's say if you had declared an abstract method in that non-abstract class-it's impossible to call that particular abstract method. (to prevent that, we can't declare abstract methods in non-abstract class )

Looking at it the other way, if you are defining a method as abstract that means you are surely inheriting that class to some other class/classes otherwise no use of defining it as abstract. Moreover, you should keep abstract methods in those classes which are parent class and have members that are inheritable and characteristics to other sub-class. So if for one abstract method a whole class is need to be inherited then we could define the other variables too with required access specifiers so that it also get inherited as needed and hence no need to create objects of parent class to call concrete members.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top