Suppose you wanted a class for a bank account. OK so far.
But then you'd probably want several classes for different sorts of
bank account - current account and deposit account at the very least, and - more
than likely - several others.
You might start off by designing a class for each different sort of bank account
that you wanted. Pretty soon, though, it'd dawn on you that this was awfully
repetitive. Or, putting it another way, that there was a good deal of
commonality between the classes.
The easy way round this is to extract all the common bits, and put them in a a class of their own - called, say, Account.
From this class Account, you'd then have a lot of "child" classes, one for each sort of account that you wanted. These children would "inherit" the attributes of their parent Account, so they'd get all the common bits without your having to write them out each time.
Each child would have its own distinguishing features, over and above the common ones that it would have inherited from its parent Account. An object of class DepositAccount would have an attibute of InterestPayable which an object of class CurrentAccount might not need to bother with. But both of them would need a ClientName. In fact, all the sorts of Account will need ClientName. So ClientName could go in class Account, neither in CurrentAccount nor in DepositAccount. But both CurrentAccount and DepositAccount would have ClientName available to them, because they would inherit it from their parent class Account.
Having got this far ... the class Account can be an abstract or deferred class, there basically for the purposes of convenience. It will not need any executable code of its own. DepositAccount and CurrentAccount, however, will have executable code.