Are there any reasons to have an abstract class with every method in the class defined?

Question

It seems that an abstract class means the definition of the class is not complete and hence cannot be instantiated.

And I saw some simple Java code which has an abstract

Answer 1

I see this question is already marked answered, but I'd like to provide another alternative explanation.

Another reason for this kind of code would be to provide a base implementation for all derived classes of that abstract class.

Then when implementing new derived classes you have a runable implementation that you can then choose to override the methods of in order to customize behavior for that derived instance.

Take the case of an BaseItemBuilder which is abstract and provides data access logic based on a common argument, such as ItemNumber.

(Sorry for the C# code but this question is pretty much just programming theory more than it's about a specific language)

public abstract class BaseItemBuilder { /*I don't want anyone using this directly but I do want the base specification*/
    public virtual void GetInfoAboutItem(int itemNumber){ 
        var infoModel = _infoDataService.GetItemInfo(itemNumber);
        //project values on to internal representation of item
    }
    public virtual void GetMoreInfoAboutItem(int itemNumber){ 
        var infoModel = _infoDataService.GetMoreItemInfo(itemNumber);
        //project values on to internal representation of item
    }
    public virtual void GetEvenMoreInfoAboutItem(int itemNumber){ 
        var infoModel = _infoDataService.GetEvenMoreItemInfo(itemNumber);
        //project values on to internal representation of item
    }
    public virtual void GetYetMoreInfoAboutItem(int itemNumber){ 
        var infoModel = _infoDataService.GetYetMoreItemInfo(itemNumber);
        //project values on to internal representation of item
    }
}

You could then derive a NormalItemBuilder which uses the base implementation. This accounts for 80% of the items that you are tracking.

public class BaseItemBuilder { 
    /*I use the base implementation!*/
}

Then you derive a SpecialType1ItemBuilder that goes to a couple of different data services to acquire information about that particular item type, but still uses some of the base implementation defaults. This covers the next 10%.

public class SpecialType1ItemBuilder { /*I don't want anyone using this directly but I do want the base specification*/
    public override void GetInfoAboutItem(int itemNumber){ 
        var infoModel = _infoDataService.GetType1ItemInfo(itemNumber);
        //project values on to internal representation of item
    }

    public override void GetYetMoreInfoAboutItem(int itemNumber){ 
        var infoModel = _infoDataService.GetYetMoreType1ItemInfo(itemNumber);
        //project values on to internal representation of item
    }
}

Then you derive a `SpecialType2ItemBuilder' that goes to yet another set of sporadic dataservices to complete a picture of that item. This one goes overrides another set of methods that are different from Type2ItemBuilder. This covers your last 10%.

public class SpecialType2ItemBuilder { /*I don't want anyone using this directly but I do want the base specification*/
    public override void GetInfoAboutItem(int itemNumber){ 
        var infoModel = _infoDataService.GetType2ItemInfo(itemNumber);
        //project values on to internal representation of item
    }
    public override void GetMoreInfoAboutItem(int itemNumber){ 
        var infoModel = _infoDataService.GetMoreType2ItemInfo(itemNumber);
        //project values on to internal representation of item
    }
}