I have decided to start doing small coding projects on my own that focus on code quality instead of code quantity and have a question about the use of abstract classes.
Strictly from a design perspective, it is best to simplify things. I believe the best way to simplify things is to use a simple analogy. Let's use an analogy of birds...
Interface: use this when you want to enforce certain functions which need to be defined. e.g. IBird has a contract for ScreamLikeABird and Fly (interface functions). But you can get more specific and have an IOstrich that has a Run contract. You may also have an IHawk that has an Attack contract...etc.
Abstract: use this when you want to enforce base functions and have base properties. e.g. Avian could be a base class for birds which may have a function called LayEgg as well as propeties called Age, Species, NumberOfChicks...etc. These things don't/shouldn't change the behavior of a bird, since all birds lay eggs...etc. But not all birds sounds the same when it scream or flies the same way (some dont even fly)....etc.... hence they should be implemented via an interface(s).
Abstract Classes vs Regular Classes vs Interface. Abstract class usually supports an idea of the generalisation and to contribute from programmers to keep a quite little brain disipline by designing multi-years projects because of they when include an abstract methods have to describe an implementation that abstract methods in subling classes, however, this feature is a disadvantage for a short-time projects when a developer have a zeitnot.
The only reason for declaring a class as abstract is so that it can't be instantiated. There are situations where you will have common functionality that is shared between a number of classes, but by itself that common functionality does not represent an object or represents an incomplete object. In that case, you define the common functionality as abstract so that it can't be instantiated.
in my opinion abstract classes have more use in real projects as on books. some times project managers just provide the methods declaration and you have to write code for the methods without modify the core syntax provided by manager. so that is how an abstract class is use full. in simple class method define,declared and coded in same time but not in abstract classes. for ex:-
abstract class Test
{
abstract void show();//method provided
}
class Child extends Test
{
void show()//coding
{
System.out.println("saurav");
}
}
class main
{
public static void main(String[] args)
{
Test c = new Child();
c.show();
}
}
In automotive manufacturing terms, an Interface is a spec sheet for a "car" which says it has four wheels, five seats, an engine, etc, while an Abstract Class is a partially assembled car in a crate that you have to finish off to your own requirements. E.g. Subaru uses the same exact chassis for the Impreza, Forester and XV/Crosstrek. So the chassis is the "abstract class" which has common features and functions but isn't a "car" yet. The body and interior MUST be added after the fact before you can say you've built a car. The engine is also common among all three, though you can choose to swap it out for a turbocharged version IF you wish.
In addition to not being able to create instances of abstract classes, some languages may support having abstract methods in abstract classes - similar to interfaces, an abstract method will have to be implemented by the class inheriting from the abstract class.
The main benefit of abstract classes in my opinion is if there is some code that has to be shared between classes of the same type. Usually you could use an interface for this, but sometimes the functionality of such classes may overlap and you would end up with code duplication. In this case you can use an abstract class and just put the code there.