Object-oriented programming isn't completely wrong. Actually, it's often a very good thing to do. The point I wanted to bring out with the title of this post is that object-oriented (O-O) programming isn't always the right thing to do, which is something that O-O devotees sometimes have extreme difficulty in accepting. It can be an architectural disaster if you don't get this right in your applications.
What motivated me to get into this topic was Martin Fowler's piece which discusses, in some detail, the differences between the purist approaches to O-O design and the approaches that actually make sense in practice. Now, for the most part, I agree with what Fowler wrote (and I'm not a Fowler worshipper, I don't agree blindly with everything he writes). However, one paragraph troubled me. He wrote:
Another good warning sign of trouble is the Data Class - a class that has only fields and accessors. That's almost always a sign of trouble because it's devoid of behavior. If you see one of those you should always be suspicious. Look for who uses the data and try to see if some of this behavior can be moved into the object. In these cases it can be useful to ask yourself 'can I get rid of this getter?' Even if you can't, asking the question may lead to some good movements of behavior.
It isn't that this advice is always wrong, just that it is only right in a particular context that Fowler didn't make clear, and so some of his fervent devotees may unduly misinterpret the advice. However, I need to put things in context to explain why.
Object-oriented programming is a programming style that involves a tight binding between data and the methods/functions that operate on that data. So classes in O-O languages have both data and methods, and it is considered poor form to allow external classes to do any significant manipulation of the data within a class. This approach works very well within individual applications for data that resides in memory. The popularity of O-O languages such as C++/Java/C# is a direct result of how successful the approach is in this context of application code working on in-memory data.
The object-oriented approach has been an abject failure for data persisted in long-term stores, such as databases. Object databases failed completely to wrest any notable market share from relational databases, and are only used in a few niche areas. Why? Well, when I have talked to people who have worked with object databases, the clear message is that the tight binding between code structures in applications and data in object databases makes it very difficult to introduce necessary changes to the in-memory data models of applications. Object databases never found a good mechanism for coping with changes to data structures without having to do a complete rebuild of the database (which is not an option for large enterprise databases). They are fast, and they work if your data structures really aren't changing over time, but that kind of environment is the exception rather than the rule, and hence their niche status.
Much the same can be said for XML databases as for object databases, although XML itself has been a great success as a data format that separates data from functionality in a way that is the antithesis of the O-O approach. The XML approach certainly isn't the way that you would want to do all of your in-memory data processing, but it does work extrememly well for storing or transmitting many types of data, i.e. it works between in-memory invocations, either between different applications/machines or between different points in time when the data needs to be accessed.
This brings me back to Fowler's comment about data classes being a sign of trouble. I agree with him for data classes that are only used as part of the in-memory processing of data. However, most applications also need to deal with serialised (stored) data as well as with in-memory data. For reading and writing such data, data classes are a really good idea. They give you a point of access to the data that isn't bound to a particular application and isn't burdened with methods that implement business logic that is specific to the application. These data classes can often be auto-generated from database or XML schemas, which has the advantage that you know the data classes can be serialised because that are derived from a serialisation format; some in-memory data structures are difficult to serialise because they don't fit into a tabular or tree structure, and it's often better not to try to serialise them in that form. There are some data structures that work well in-memory, and other that work well for serialisation, and you can waste a lot of valuable time in your software development if you don't use the right data structures for the right parts of the job.
These data classes for serialisation are not O-O, because they don't implement methods specific to the processing of the data. Instead, that is left to external classes. They work well because the O-O approach just doesn't work well for serialised or persisted (stored) data. That shouldn't be seen as a failure of the O-O approach; as noted, it is a very successful approach in the right context. It's just that there are wrong contexts for it, and we have to be broad-minded enough to recognise that in our software architectures.
Object-oriented programming isn't completely wrong, but nor is it completely right in every context. It has it's limitations, it has its sweet spots, like each and every tool in the software developer's arsenal. Let's not forget that.
RSS 1.0
Follow me on Twitter