When designing an object-oriented program, you begin by identifying the real-world entities in your problem domain. For example, when managing your personal finances in the real world, you have to deal with checking accounts, savings accounts, checks, money, budgets, mutual funds, credit cards, stocks, bonds, and banks, among other elements.

Define the classes that model these real-world entities. Generally, your classes will be the nouns that figure in your problem domain. Thus, you might have classes called:

Defining your own classes with easy-to-understand class names makes it much easier to keep track of your design. Traditional programming tries to make the real world look like a computer's memory.
Object-oriented programming tries to make a computer's memory look like the real world.

Avoid class names that describe computer concepts like stack or array, as well as names that are built from verbs. The idea is not to describe a computer program, but to describe a business situation. Verbs make good names for methods (also called functions) but bad names for classes. Here are some poor names for classes:

1. CheckArray: Try CheckList or ListofChecks instead. It does not matter how it is going to be represented in the computer.
2. Balancer: What does it balance? For example, if it balances an account, use Account as the class, and when you add responsibilities you can include balances itself as a responsibility.
3. StatementPrinter: Statement is a better choice.
4. TransactionStack: Try Transactions. The way it is represented does not matter.

Stick with class names that are simple nouns from your problem domain.