How Far Can Banksters Go With Object Oriented System Design?

The answer?  All the way to the Super Class of Account dominant class determining structure of the system.  The fundamental question in creating object oriented systems is:  Now that we have named the Super Class, what is a uniquely identified instance of the Super Class that makes it different from all other instances of the class.

A numbered account is a unique instance of the Super Class of objects called Accounts.  The rule is that no two or more accounts can have the same unique identifying numbers.  Just ask any Swiss Banker.


Financial Accounts are often used as textbook examples for object oriented programming.

The Super Class: Financial Accounts has sub-class accounts of various types.  For example, checking, saving, etc.  All inheriting some attributes and methods from the Super Class: Financial Account.  One thing they all deal with, is Money.

This link for example:

Money as a data element of an  account is defined a variable called "balance".  A numeric value object in the Super Class: (for simplicity) Numbers that has the attributes of all numbers and can do all the things that numbers know how to do:  add, subtract, etc.

The concept of money to a bankster is a numerical balance in an account.  An account balances, in the macro analysis and macro management system to a asset/liability balance in another account.  Money is a number in an account, that is all it is.  A number initially created out of thin air brought into existence when it was initially put into an account by the bankster as a loan, moves among accounts of different holders during its existence and finally goes out of existence as the loan is repaid.

The only concept of money being an object to a bankster is cash currency dollar bills and coins.  In that form it is a minor thing and is the least of a banksters concern except probably as a the pain in the butt detail that banks have to take care of. 

When a business defines itself in an object oriented model the system analyst looks for all the main objects that the business deals with in order to model their business.  All businesses deal with money so that is obviously one of the major objects in the system to model in some way.  In a prior post in this blog I discussed a comment about the danger of object oriented modeling creeping into the banking world.  I conclude that the danger is that in modeling the banking world there will be an inclination to treat money as an object, not just a number called a balance and construct the object model accordingly.

I can see the scenario.  An object oriented system designer looks at the business practice where accounts are a major object class, sees that money is only a data element number in an account and is inclined to model it as major object class in the management system.  Taking the idea to management the system modeler is told:  We don't do business that way.  If the system analyst says that it would be more efficient this way I expect that they would be efficiently fired.

In the world of positive debt free money it becomes an object class in the system.  Money is a Super Class with many subclasses.  In all cases a unique instance of digital money at the unit level with a unique serial number identifies it from any other unit instance.  It might be a digital dollar but essentially it is a unique object no different than a serialized, denominated paper dollar bill.

On some of the money/economics blogs there is a person who comments on and attacks any idea that suggests that money is an object with the implication or flat out statement that positive debt free money is an object that cannot exist.  He says that is the wrong idea of money.  Money is only a balance in an account.

An account as a Super Class in Java:

http://java.about.com/od/workingwithobjects/a/useinheirtance.htm

Here is  programmer that is as puzzled as I am that money is not treated as a class of object in programming:

http://martinfowler.com/eaaCatalog/money.html

http://www.codecodex.com/wiki/Money_Utility_class

"A large proportion of the computers in this world manipulate money, so it's always puzzled me that money isn't actually a first class data type in any mainstream programming language. The lack of a type causes problems, the most obvious surrounding currencies. If all your calculations are done in a single currency, this isn't a huge problem, but once you involve multiple currencies you want to avoid adding your dollars to your yen without taking the currency differences into account. The more subtle problem is with rounding. Monetary calculations are often rounded to the smallest currency unit. When you do this it's easy to lose pennies (or your local equivalent) because of rounding errors.
The good thing about object-oriented programming is that you can fix these problems by creating a Money class that handles them. Of course, it's still surprising that none of the mainstream base class libraries actually do this."

Is LoanedMoney a sub-class of  Money or a state of money?  I can imagine a number of sub classes (or states) of Money when money is all serialized and digital in value units of one in a real money system replacing a debt money system.