The Stripper Pattern

time to read 3 min | 502 words

image In 2006 (if I can recall correctly), Greg Young and I discussed the concept of the Stripper Pattern, we never really had the chance to formulate it into a real pattern, but we kept discussing this whenever we met (and had beer available).

This post is about the stripper pattern, and there is a good reason why I selected the accompanying image for this post, it is the spookiest stripper image that I can put in the blog. Because the Stripper Pattern is an anti pattern.

It all started from a fairly innocent question, asked in the NHibernate talks that I did on Progressive.NET:

How can I send my objects over the wire?

I could have given the answer, I could have talked about the reasons this is bad (versioning, isolation, tell don’t ask, etc, etc), but what I actually said was:

I'm not running a strip club so why am I sending you all my privates?

Later on, we got into a deeper discussion of the topic, which led to this post. There is a reason that I choose that statement to answer that question. Let us move up the stack a bit and ask: What is an object?

An object is data + behavior. If you don’t have behavior and data, you don’t have an object. It is as simple as that.

Nitpicker corner: I am not talking about System.Object, or something of the sort. I am talking from a conceptual level. DTO is not an object, despite the name, it is a bag of data.

Since it is not possible to send behavior over the wire, what the question means is actually:

How can I send my objects as data over the wire?

The problem is that this question doesn’t really make sense.

What you are actually doing is divesting the object from its covering and perform acts of forbidden knowledge on its privates. Then, to add grave insult to serious injury, you take that and post it over the internet.  Just be glad that objects can’t sue for breach of OO contract, encapsulation violation and sexual harassment.

When you separate a data from behavior, you are no longer working with objects. At that point, you start to run into problems, a lot of them. In addition to the simply technical issues, there are very serious architectural issues with stripping away all OO from your solution.

If you need to send data over the wire, that is why we have  a DTO for. If you need to handle updates, use the approach described here, which gives us a good OO semantics for the whole process.