Contract versus Coupling

Alan Stevens (@alanstevens for use Twittering Twidiots — had to use that word in a sentence at least once today) spurred some further thoughts on coupling and I just HAD to share.

A few years back, I was mentoring a colleague on SOA concepts. We got into the idea of serializing objects and what is a good idea and what is not. The app we were working on serialized objects of a certain type, but needed to reconstitute as a separate type. As the objects contained behavior (a pet peeve of mine), it was a sticky, stinky mess.

That led to a discussion about whether or not I felt serialization of objects is a bad idea, as it would necessarily couple the two applications. No, I stated, it need not couple.

Coupling is evident when you have to update libraries on both the front end and the back end, or the client and the server, if you like those terms better. If you update to version 2.0 on the back end and I can continue using 1.0 objects, then the coupling is still pretty loose, at least as far as the communication at hand. The application I am working on now required a complete revamp of the client (web app) due to a change in the back end libraries (they share the same libraries and the objects contain behavior, including communication hooks — ouch!!!).

Well, Alan mentions that many advanced devs do this. Yes, the vendor that wrote the back end has some very advanced, very smart people, so I can concur. And the app from a few years ago had a very smart guy as their "architect" before I was onboard. I have also cleaned up after some real first rate morons, as well, but that is something I will save for a rant post. 🙂

Back to the subject at hand. Talking from one application to another requires that you agree on how to communicate. You are not coupled if you agree that you send two integers to me and I will return you a single integer or a double or even a string. The same is true if we agree on more complex objects than simple data types (although strings are not really all that simple, are they?). This is the world of contract. You pay me $X and I will program for you for an hour. That is the essence of a contract.

Now, if I state, you send me an X object, using the 2.0.3456.364 library, and that gets into coupling, as you are not only stating the information I have to give you, but the exact method I have to use to get it to you. And, that locks me into your back end, as nobody else has access to your types.

Let’s call this rule #1: If you have to agree to particular versions of libraries, not just object forms, you are tightly coupled.

Rule #2 then would be: If you have to talk to a particular application and cannot move to a competitors version of the application, you are tightly coupled.

Rule #3: If you cannot move from one type of data store to another, you are tightly coupled.

Ooh, and here is a tricky one: If you place your business logic into you UI … oh, wait, maybe that is you are ignorant rather than tightly coupled. ;-> (Before getting too pissed off, consider that the word ignorant is better than the word stupid. Ignorance is curable, stupidity is not).

If you have to update libraries, you most likely have a versioning issue, as well. You know, simple things like breaking the rule "NEVER change a public interface".

Peace and Grace,


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: