Abstract Classes in C++
As intellectually satisfying as factoring is in C++, it introduces a problem of its own. In an example about bank account classes, specifically the common base class Account. Think for a minute about how you might go about defining the different member functions defined in Account.
Most Account member functions are no problem because both account types implement them in the same way. Implementing those common functions with Account::withdrawal() is different, however.
The rules for withdrawing from a savings account are different than those for withdrawing from a checking account. You’ll have to implement Savings::withdrawal() differently than you do Checking::withdrawal(). But how are you supposed to implement Account::withdrawal()?
Let’s ask the bank manager for help. The conversation could go something like the following:
“What are the rules for making a withdrawal from an account?” you ask.
“What type of account? Savings or checking?” comes the reply.
“From an account,” you say. “Just an account.”
The problem is that the question doesn’t make sense. There’s no such thing as “just an account.” All accounts (in this example) are either checking accounts or savings accounts. The concept of an account is an abstract one that factors out properties common to the two concrete classes.
It is incomplete because it lacks the critical property withdrawal(). (After you get further into the details, you may find other properties that a simple account lacks.)
An abstract class is one that exists only in subclasses. A concrete class is a class that is not abstract.