Objects. Encapsulation. XML?
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
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.
Uche Ogbuji is a consultant and co-founder
at Fourthought Inc. in Boulder, Colo.
He may be contacted at email@example.com.