Why Object Oriented Encapsulation is Obsolete

Share the article!

Bill de hxc3x93ra has a thought provoking blog entry wherein he writes:

A key thing for XML pipelining is that you want to separate data from process acting on that data, which is heresy in some OO circles. The only process really tied to an XML document is schema validation, and even then the behaviour is so data driven, so late bound it’s hardly worth picking it out. Off the top of my head, I can only think of one OO pattern where it’s ok to decouple data from behaviour and it’s the Visitor. It seems that at the system edges, where XML does matter, functional programming and lazy evaluation are the way to go.

Bill writes about two concepts, that is pipelining which leads to lazy evaluation. A week earlier I wrote about “Lazy evaluation” but I was looking at it from a different angle. That is from the point of view of composition, however the reference I pointed to mentioned the Decorator pattern. The Decorator pattern is precisely how you implement pipelining in an OO language.

Another slant that I’m interested in is how encapsulation seems to be problematic for “programming in the large”. Uche Ogbuji has got something to lend to this discussion. He proposes functional languages as an alternative means for handling “side-effects”:

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.

Unfortunately, I seriously question the usefulness of “languages without state“. The primary reason why declarative systems exhibit loose coupling is due to the fact that scheduling is more flexible. This however, pertains to the decoupling of behaviour or sometimes called “lazy evaluation” and not the side-effect free properties of functional languages. The “side-effect” free property is something mathematicians love, however it’s a real stretch to the imagination to believe that it’s applicable in the real world. Just ask anyone writing something complex in XSLT for evidence.

The key to composable systems is that behaviour cannot be encapsulated with data. Decoupling of data and behaviour seems to be counter the goal of OO encapsulation. On the otherhand, if we treat encapsulation as information hiding in the form advocated by Date. Then we can have encapsulation (i.e. information hiding) combined with data/behaviour decoupling and eat our cake too!

Share the article!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>