I got several explanations but so far I'm not able to understand that what are the abstract classes and methods in Java. Some said it has to do something with the security of the program, other said it isn't anything like that. Even from the Dietel & Dietel's book I don't get it's purpose. When, where and why do we use it?
An abstract class is a class that cannot be instantiated (i.e.
An abstract method is a method in an abstract class that can be overridden (i.e. implemented) in a derived class.
The difference between an
With abstract classes you can have some kind of skeleton for other classes to extend.
You can't instantiate them but you can put some common implementation which you can use in the classes that extend them.
A real life example of an abstract class would be Human for example. But would you intantiate a Human object? No! You would further derive classes from the Human abstract class like Infant, Child, Adult, Man, Woman, etc. And you will extend/retrict the original behaviour in these derived classes down in the heirarchy.
An abstract class is a class that implements some common functionality used by one or more concrete (not abstract) classes.
A good example of this would be the AbstractList class in java. This class is extended by
One would never instantiate an
An abstract method is a method that is not implemented in an abstract class or interface, but must be implemented in the concrete class.
The core reason why one would want to have a method be abstract is to be part of a public API. If you the
First of all, the examples will be in C#. But I think you'll have no problem understanding it. So...
You CANNOT instantiate objects of an abstract class. You must have a subclass that derives from the class, if you want to instantiate it. But this probably won't help you since you may have come across that before.
So let's try an example.
Suppose you want to lose weight and your nutritionist asks you to track your food intake. When you go to her again, you can't tell her that you ate a "food". Although it's not wrong, since all food has calories, it is too "abstract" for her. So you need to tell her WHICH food.
So, if she were to code that... She'd have an abstract class Food.
Why? Because that wouldn't allow you to say "I ate a food".
So you need concrete classes:
So you'll have to tell exactly which food it is.
But she still needs the food class, it is still interesting to her:
That's an example of when you need an abstract class. When you want to have a base class, but you don't want anyone creating an object of your class.
An abstract CAN have abstract methods. It doesn't need to. Is totally ok to have an abstract class without abstract methods. Speaking of which...
Abstract method is something that it's too broad. There's no similarities on how things work, so the classes that derive from your class that has an abstract method won't be able to call the super class implementation. And you're also forcing all the sub classes to implement their version of that method.
Let's try another example? An Animal Band Simulator. You'd have animals, and each one of them would make a sound. But those are very different "implementations", they have nothing in common A dog differs from a cat, a cat from an elephant, an elephant from a cricket. So you'd have an abstract method MakeSound.
But, if you have an abstract method in your class, that makes the whole class abstract!
So the rest of the code might be:
And the BAND!
So this is an example of when you use an abstract method.
I guess this is the essence. It may be a little forced/convoluted, but I think it gets the point across. Go back to the examples that didn't help you before and see if they make sense now.
I'm go out on a limb and say you're a beginner. This stuff may seem strange to you, and you may not see any benefit in using abstract classes.
It's ok. It's strange for almost all of us when we start. But in time, you'll learn to appreciate it.
An abstract class/method is, conceptually, a "starting point" for a concrete implementation.
An abstract method or other member cannot have any code; it is quite literally a placeholder for a member that must be implemented by classes deriving from the abstract base. It's similar to a method declaration in an interface, but an abstract class can define abstract members of any inheritable visibility, not just public. That abstract member can be used in any code in the abstract class. The purpose is usually to allow the deriving class to specify some implementation-specific logic or behavior, whose extraction from the surrounding code makes that remaining code implementation-independent.
An abstract class cannot be instantiated; it exists to be derived from and to be used as a common type for members and parameters, similar to an interface in this respect. Classes with any abstract members must themselves be marked abstract, but a class with no abstract members can also be marked abstract. Thus, abstract classes can have code in non-abstract members, which is the primary difference from an interface (the other key difference being the ability to define abstract members less visible than "public"). This is a common tactic to share (and thus re-use) code that is common between implementations of the abstract class.
As far as when to use them, succinctly, use an abstract class whenever you would normally use an interface, but when you also wish to define code that can be shared among derived implementations of the base.
There are differing best practices between Java and C# regarding whether to combine interfaces and abstracts in the same inheritance hierarchy. It's been my experience that an interface directly implemented by a single abstract class is redundant in Java due to naming conventions (interface names are supposed to look like class names so coders don't have to care what they're using). In C#, the pattern's still considered a bit "deep" but is more acceptable because the interface, by convention, would be prefaced with "I-". Either way, the arrangement allows even the abstract class to be refactored or replaced without affecting dependent classes; not only can any implementation of an abstract DoerBase be used, but any Doer (or IDoer) including an implementation of a new BetterDoerBase, or a concrete class inheriting directly from the interface.