Encapsulation and Representation are Orthogonal

David Bau has written a blog entry about the tradeoffs between Encapsulation or Representation. In summary he brings forward a few rules of thumb:

1. Use encapsulation when your program outlasts your data.
2. Use representation when your data outlasts your program.

Encapsulation, therefore, is still the main technique to use when implementing a single tightly-coupled computer system. However, as soon as we move to larger, more loosely-coupled networks of systems where individual programs can come and go while the network of data exchange remains, data representation becomes a much more powerful technique.

1. Use encapsulation to subdivide tightly-coupled components of a system.
2. Use representation to connect loosely-coupled systems together.

I had covered the loosely coupled nature of Representation or Document Passing as I had called it in an earlier piece. However, if you examine my table on loose coupling, you'll realize that these two concepts are actually orthogonal. Encapsulation concerns itself with a interface specification and Representation is about schema specification. The confusion stems from the fact that in our traditional models many aspects are intertwined together. For example in the above article, Encapsulation is a combination of interface (method based), messaging (procedural), synchronizaion (synchronous), schema (grammar based) etc.

The explanation of Representation really concerns itself with a subset of capability introduced by what the author means by Encapsulation. However, what was missing was the mention of other aspects like interface (REST) and sychronization (asynchronous).

I believe the author may have omitted the fact that for two systems to interoperate in representation they have to agree on some standard. Preferably that standard is not implicit. That is, it is in the explicit form of a XML Schema (i.e. Grammar based) or something like Schematron (i.e. Pattern based).

On second reading, the author actually fails to make the argument that representation is better for loosely coupled systems. The author only points out that representation should be used in systems where the data model remains static. That seems extremely unrealistic given the Laws of Software Complexity.

Pieces like this do promote awareness of loosely coupled principles in software design, unfortunately it exhibits a poor grasp of the underlying concepts. The saving grace of the piece is that it hightlighted the distinction between small and large systems.