I recently read a blog on the Intel Software Network describing the reduced execution flow readability in object-oriented systems that implement a domain model as being a "flaw" in object-oriented modeling.
I disagree completely, as a procedural (better execution flow readability, and the approach recommended by the author) approach is just a different animal compared to a modeling approach (which focuses on conceptual clarity, not execution steps).
The post (http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/) was partly correct that modeling can reduce execution path redability, however it was incapable of providing a "flaw" in object-oriented modeling. My response was a good exercise in articulating the real reason behind object-oriented modeling: to use a model to manage complexity in business domains. See my response in the comments, but I've also reproduced it here.
Thanks for your post! It gives an excellent path to some vibrant discussions.
I would like to focus on the title of your post, and how I don't believe the "flaw of object oriented modeling" is a flaw at all but rather two different approaches to programming with each one best suited for different contexts.
You say, "Object Oriented Modeling was invented to help developers manage the code", but this is not entirely the case.
Modeling real-life systems has been around for many hundreds of years, though surely longer. Modeling can be found throughout many disciplines including engineering, architecture, mathematics, et. al. As mentioned above in previous comments, which I fully agree, modeling is an approach to problem solving that helps manage complexity in a given domain. Trying to implement a model in software can become difficult using languages that are not well-suited for modeling. Object-oriented languages are a better fit for models because of their state+behavior (object) approach. Procedural languages are not as good because they're focused more on completing certain predefined tasks and not on capturing the concepts in the model. Object-oriented modeling is the implementation of a model with an object oriented language and can reap the great benefits of modeling. To say it was invented to "help developers manage the code" is entirely simplistic and misses the point of modeling in the first place.
On the other hand, you're somewhat correct when you say modeling in software reduces the ability to follow an execution path. The reason is simply because modeling is focused on concepts and behavior, and not a predefined, task-oriented, series of steps. Therefore, the reason you put forth for a "flaw in object modeling" is no flaw at all. It's a completely separate approach for solving a problem. If the problem has to do with mathematics and physics, no doubt you would model it. If the problem has to do with a complex business domain, a model will help manage all of the complexity found in such a domain. If your problem is writing device drivers or embedded systems software, a procedural approach probably would be more appropriate.
Can you write device drivers using a modeling approach with an object-oriented language? Probably. But it might be overkill, muddy the tasks taken to perform the driver's functionality, and obscure the execution path.
Can you write complicated business logic in a purely procedural manner? Probably. But the software would end up looking like a monstrous tangle of functions without key active elements in the domain clearly conceptualized, and maintenance would be a nightmare as a better understanding of the domain emerges.
Your post must assume that the people who argue 'for' object-oriented modeling argue for it as a solution to every problem. That is most certainly not the case. With the understanding that object-oriented modeling, or rather modeling in general, is appropriate for certain cases, your post demonstrates no "flaw" in object-oriented modeling at all. Either focusing on concepts or focusing on tasks is an appropriate approach given the context.
Thanks again for your post.