Don't Dismiss Structure Shyness

Structure shyness is a very important aspect of agile designs, it's related in a way to information hiding.

I was introduced to structure shyness by the work of Karl Lieberherr of the Law of Demeter fame. The idea is this, when traversing an object structure, code tends to be highly coupled to the concrete structure. Structure shy traversal allows one to specify strategies that ignore certain parts of the concrete structure. This lowers the coupling of code from the concrete structure. This results in lessening the dependency of code changes when stucture changes. The idea is to capture the essential structure and ignore the rest.

Classic object oriented methodology always emphasizes the central role of class or domain modeling. The idea is that the domain model tends to remain stable over time. However, in practice this is difficult to enforce. This is because its quite difficult to strictly separate a conceptual model from its concrete implementation. Its always seems that an artificat of implementation creeps in from all over the place.

The Structure Shyness idea was extremely compelling, unfortunately it never caught on. However, with the recent development of xpath, a language to traverse XML structures, this old idea can be resurrected. In fact, Karl Lieberherr's group performed a study several years back comparing Xpath and structure-shyness. The conclusion seems to be that the expressive power of xpath was almost equaivalent to Demeter.

When you start using xpath statments like //Chapter//Paragraph you are essentially ignoring intermediate nodes and focuses only on relationships that you expect to be invariant over time. This can lead to code that requires fewer modifications in as software evolves. You could think of it as object stucture views just like you have views in relational databases.

Essentially is a kind of information hiding. If this were applied in replacement of schema based messaging, one can effectively achieve more loosely coupled systems. That is, systems will not break that easily as a schema changes. Rather you can pick and choose conceptual boundaries that tend to remain unchanged as a system evolves. Ignoring non-essential stuctural details acts as a firewall against incremental change.