But this simulation concept is not particularly well adapted to the world of business and information technology. Business is highly data driven and most business objects are defined as data. The objective of business software is typically to process input data (lots of it) and produce output data. There is little real world evidence to show that this can be done easier, faster or more efficiently using OOP.

In my opinion, unless you're creating a real world simulation of some sort that will exist entirely within computer memory, binding data and code together offers little practical, real advantage. When it comes time to communicate or store business data, the OOP code/data binding actually becomes more of a hinderance.

This is not to say that OOP is not useful. It's no surprise that one of the most popular applications of OOP is building graphical user interfaces --- an on-screen simulation of a paper data form that is built and exists entirely within computer memory.

Applying OOP to problem spaces where it is not well suited often results in slower, more complex, harder to maintain applications. Instead of spaghetti code, OOP programmers all too often tend to create spaghetti objects that obfuscate more than enlighten.