[QUOTE="Richard Damon"]\nIf we started with a\ntypedef double MoneyType;\nat the beginning of the header, and getBalance() defined to return a\nMoneyType, then if the client used the MoneyType also, then no change in\nclient code might be needed.[/QUOTE]\n\nIn the client, one can have case A (old solution):\n\ndouble b = account.getBalance();\n\nor case B (your new suggestion):\n\nMoneyType b = account.getBalance();\n\n. In case A, the client's author can then write\n\n::std:cout << 0.05 * b;\n\n. In case B, the client needs more support from the\nimplementation to be able to do this. The client's author is\nnot supposed to know that »MoneyType« is just »double«.\nTherefore, he cannot write:\n\n::std:cout << 0.05 * b;\n\n, because he does not know whether MoneyType supports those\noperations and what their semantics is. But usually the\nclient might need to calculated something with the balance\nor to serialize it to a human-readable stream. So he needs\nmore support from the library than just the statement\n»MoneyType is an opaque type that you do not need to know\nanything about.«\n\nPossibly, MoneyType might grow to become a new type\nimplemented by a class. Well, then this class better not\nhave a »toDouble()« method, because otherwise the clients\nmight use it and then the same problem will arise anew.