Maintenance and Reuse? One Out of Two Ain’t Bad!
Good OO code is substantially more maintainable that most procedural code designed to solve the same problem. As for reusability? Well, as I said, one out of two ain’t bad.
When OO design was first introduced, it was heralded as the beginning of a new age of maintainability and reusability. Now that Service Oriented Architecture (SOA) is the "next big thing", the same benefits are being touted over the failed dreams of reusable OO designs.
OO designs fail on reusability for two reason – lack of semantic richness of interfaces and necessary dependencies.
The interfaces used to describe method calls (return type and arguments along with their associated data types) just aren’t semantically rich enough to describe object interactions. They leave all kinds of questions unanswered such as what kind of message codes do you pass on error conditions? What are the full set of testable pre and post conditions for each method call? Etc.
Also, while OOP designs are loosely coupled that does not mean they are not coupled at all. An Order object is of little use without an OrderDAO to encapsulate persistence, a TaxCalculator for calculating taxes, a ShippingCalculator and so on. In practice, some companies have done quite well with reuse of objects in-house, but the goal of reusability (which is probably at more of a package or service level) has yet to be met.
But all is not lost. OO design is worth the effort for the maintenance benefits alone (as anyone who’s had to maintain a large procedural code base will attest to).
Why even mention this? Because it is important to understand why you’re doing things so you can make appropriate design decisions based upon your circumstances and your underlying intent. For me, the underlying intent of OO design is maintainability. Nothing more, nothing less.
