Yep. Unless you are writing a supply chain model that connects into your maintance department and electrical cost centers, in which case you are going to need to use the MyBossHasNoClueWhatHeIsAskingFor pattern.

More OO is all well and good except you eventually reach the point where all you can think in is creating more objects. And then performance goes to absolute Hell. OO in moderation rocks, but very few folks actually understand how to get there.

I know I have aborted (for-fun) projects because of OO design issues. I wanted everything perfect. The solution for me is to not embrace perfection and mix OO where applicable with procedural coding. OO can be used with data units, but there can still be functional/imperative constructs. So far, I'm having a lot more fun.

Professors that teach OO is the only way are really damaging the minds of their students. In some cases, OO solutions are intractible, in others they are great solutions. Chosing when and where to draw the line is the key to Software Design...something 85% (fn 1) of all software architects miss.

--- fn 1. 95.8% of all statistics are made up)