What you say is a bright example of
anti-OOP thinking. You don't need to convert from one type to another.
First of all, despite of having some different properties of different customers, they have a lot in common, such as address, name, some kind of unique ID, etc. This should be put in some abstract base type and used regardless of the customer type.
Other things should be expressed as virtual functions. Do you know this thing, a heart of OOP? Do you understand late binding? If not, it's hard to explain in full in a short answer, but the idea is that some method in a base class can call some abstract method, despite the apparent fact that it is not implemented. In a
run-time type inherited from your base type, the call will be substituted with the call to the
overridden method, closest to the run-time type. In real life, of course, nothing is "substituted", as such calls are done via a "virtual method table". In this way, some method general in signature but different in implementations, can be called in abstract base type, but the
late bound method is called during run time. In other words, you don't know what exactly implementation will be called at the point of the call; it will be found when a concrete run-time types is used.
This mechanism should give you a powerful abstraction weapon.
I want to warn you in advance: if you ask how to learn OOP and even OOD, my answer will be: learn the fundamentals from scratch; this is not a place to teach them. But let me tell you: if you don't learn OOP fundamentals very well, you can do nothing in the field you describe.
Unfortunately, it might not be as simple as that. You night need two (or more) unrelated hierarchies: for example, one deal with payments, another with options of the products you sell. While it would be the best to avoid such situation, it may be needed in real life. There are different approach to this problem:
multiple inheritance,
aggregation,
interfaces (more exactly, implementation of multiple base interfaces, which is sometimes called
weak form of multiple inheritance).
If you are educated enough in OOP (I questioned that, but in fact I an not sure about it, may be you are), read my article on the topic, where I put forward my own approach to
parallel hierarchies, among other things:
Dynamic Method Dispatcher[
^].
—SA