Use of non-abstract method and constructor in an abstract class

Question

I am beginner to Programming language. I have a query regarding abstract class.

Abstract class can't be instantiated then what is the use of nonabstract method and constructor in an abstract class .....?

please help....

Answer 1

It will make sense only when there are derived classes.

You may want some common methods to be implemented in the base class. Also, you may want to initialize a few thinhgs in the abstract class so you need a constructor.

Look at this example:

abstract class Fruit
{
    private Logger log;

    // init private stuff
    public Fruit() 
    {
        this.log = new Logger("C:\\Temp");
    }

    // do common functionality
    public int CalculatePrice(double weight)
    {
       return weight * GetPricePerKilo();
    }

    // specific stuff must be implemented by derived classes
    public abstract double GetPricePerKilo();
}

class Apple : Fruit
{
    // must implement in non-abstract derived class
    public override double GetPricePerKilo()
    {
        return 4.30;
    }
}

Answer 2

Abstract classes are there to abstract certain behaviour, while also forcing that you add at least some sort of behaviour to make it an actual object. Think of it as road vehicles. You could have an abstract class RoadVehicle that contains a non-abstract function Drive . If you then inherit from the abstract function, let's say a concrete class Car , we will already have access to the Drive behaviour.

If you don't want to predefine behaviour, you are better off using interfaces which only contain definitions of methods (and properties) every class implementing that interface should have. Ie we could have an IVehicle interface that has a method Move() . Well, land vehicles, air vehicles and water vehicles all move in a different way and thus it makes no sense to predefine behaviour, while in our previous case the behaviour was the same and we could already add that behaviour to the abstract class.

Answer 3

Abstract classes are most useful in situations where some member will have behavior which every implementation will handle independently. Consider, for example, a ReadableDoubleMatrix class, with three properties:

int Rows {get;};
int Columns {get;}
double this[int row, int column] {get;}

The simplest general-purpose implementation might be an ImmutableArrayBackedMatrix class which contains a double[,] which is filled in when the class is constructed, but other implementations would include IdentityMatrix which contains a size value [ Rows and Columns both return size , while this[row, column] will return row==column ? 1.0 : 0.0 row==column ? 1.0 : 0.0 ]. Because those derived classes have no fields in common, it would be senseless for the base class to include either. Without any fields, however, there's nothing meaningful a base-class instance could do with those properties.

Note that even if though one could eg have the base class implement Rows and Columns to return 1, and this to return 0.0, and code might in some cases find such an object useful, there wouldn't be any reason code should want to have multiple instances of such an item. Even if code had frequent need for such a matrix, and wanted it to be a different type from all the other matrices, it would generally be better to use for that purpose a sealed type.