Columns

Objects. Encapsulation. XML?

• By Uche Ogbuji
• December 1, 2003

According to software development alchemists, the Philosopher's Stone is code reuse. An organization solves a software problem once and -- "poof" -- it never has to solve that problem again. Once the Philosopher's Stone is found it leads to an endless supply of gold, which in this case is lower dependence on programming staff. (Why programmers are treated as a negative resource is a topic for another column.)

What are the great secrets of this alchemy? It depends on whom you ask. If you ask OO programmers, they'll tell you the key is to hide data behind careful code modules, i.e. encapsulation. This allows you to adapt the code modules to other uses by rewriting only the layer of code that has the most intimate contact with the data, maintaining the behavior of the remaining abstract layers. Polymorphism becomes the main tool for this matching of semantics. If you ask database or markup experts about code reuse, they'll tell you that you want data reuse since code in itself is not valuable; it is the data it handles that is valuable. Next you'll hear that data reuse comes from making the data as plainly accessible as possible so that different generations of code can evolve to address it.

How strange, then, that so much of the OO world has taken to the XML bandwagon. In many ways, these two technologies rely on diametrically opposed principles. This paradox is just an extension of the improbable alliance between OO and relational database (RDBMS) technology. Again, the core principle of RDBMS is not data hiding, but rather rationalization of wide open data using formal axioms. The OO camp has always assumed that objects would eventually tame those wild databases by providing tidy object/relational wrappers, but after more than a decade of cordial relationship, there has been precious little to show of a true meeting of the models.

Yet there are few signs of disillusionment with the OO/RDBMS partnership. One still expects, when taking on an enterprise project (and, increasingly, an open-source project), to bring OO and RDBMS heads together into the team. Never mind that the clean-room design always proceeds from the point of view of one camp or the other, and is then tossed over the wall to the other side in the hopes that they can work it into something serviceable. OO/RDBMS has always seemed a cold but committed marriage.

Lately, it's just as natural to throw OO and XML folks together in development teams. XML promises simpler code and easier extensibility than RDBMS. Interestingly, though, XML makes data even more readily available than RDBMS technology, which would seem to increase the strain on the partnership. Perhaps the key benefit of XML will be that it eliminates this strain entirely by finally putting encapsulation in its place.

The goal of encapsulation is to minimize the bugs that come about when a programmer accidentally mutates variables in an unexpected context. This error, probably the most common in procedural languages, follows from heavy reliance on expression side effects in these languages. Procedural languages have been the mainstream since the explosion of the deceptively simple BASIC language in computer education. The structural programming movement of Nicklaus Wirth and company denounced global variables as a way of ensuring programmers fine control over global side effects. Most languages that we think of as OO these days are just procedural languages with some OO scaffolding on top. (Yes, even Java and C#, which were supposedly designed to be fresh, clean and OO to the core.) One still needs to control global side effects for safety, hence the need for encapsulation.

There are other means of avoiding problems caused by global side effects. One of them is to adopt programming models in which side-effects are uncommon, such as functional and declarative programming systems. SQL, the champion language of RDBMS, is a declarative system and just as OO folks tried to tame SQL with wrapper modules, so SQL tried to tame OO languages with declarative, rules-based frameworks to direct all data processing. This didn't work, partly because declarative programming has developed quite the reputation among procedural developers for difficulty. Even though SQL-C and SQL-J were superior ways of managing the OO/RDBMS partnership, the more convenient ODBC and JDBC prevailed, essentially nullifying any benefit from the declarative data design.

XML technologies also bring a strong bent toward functional and declarative programming styles. From the natural connection from XML to LISP S-expressions, to the declarative flavor of XSLT, XML provides every reason not to mourn the loss of encapsulation. As XML processing tools in the OO space creep closer and closer to natural XML idioms, the importance of axioms (think explicit "business rules") in ensuring data safety will change the way we look at code/data interaction.

The partnership between XML and OO will be successful if XML finally gets OO programmers to accept declarative approaches to programming. If data processing is founded on axioms rather than encrypted into procedural code, then there is an opportunity for developers (and we hope not just cost-cutting managers) to gain all the benefits attributed to code reuse. There may be no such thing as the Philosopher's Stone, but by digging in the right spot, we might find all the gold we want.