Once in a while I am part of a discussion, typically more of a complaint, that a certain design is not OO. OO as in object oriented.
While that is sometimes a not so well thought through statement anyway, there is something to it. I don’t have a problem with that though, and I am not sure why anybody would. As if OO is something valuable without justification.
Of course it is not. And many have written about it.
In the field that I am mostly concerned with, data driven applications, if not “the same old database apps”, I would go as far as saying: Of course it is not OO. The whole problem is so not OO – no wonder that the application design does not breath OO.
Unlike a desktop application, where the transition of what you expect to interact with as a user kind of naturally, at least on a naive level, translates into an object oriented design, this is only on a very, very, really super much abstract level the case with data driven applications.
That requires some clarification. The term data driven application does not make sense in the singular form. There is always data driven applications. Otherwise you would hardly mention the “data” in the term. As the term suggests, the assumption is that there is a highly semantical, well-defined (not necessarily as in good) data model that makes sense in its own right. And there is many applications that make sense out of it, provide ways of modification and analyse or cross-connect with other data and applications.
It is not far from here to a classic:
Data outlive applications
Or as a corollary:
Data is not bound to its methods, methods are bound to their data.
But that’s what OO in data driven applications tends to do: It ties not only methods to data – but instead also tends to tie data to methods. As for example in OR-Mapping – if you want to call that OO.
That is of course non-sensical and would undermine all modularization and development scale-out efforts – unless of course its the data of essentially a single application. Then, and only then, it makes sense to consider it the state of the objects that in turn describe its methods.
It is still perfectly meaningful to use object orientation as a structuring means offered by a programming language. Objects will typically not represent database backed state – other than as so-called value-objects. But that does by no means diminish the usefulness of object oriented language features.
z the world 