Sonjaya Tandon

• Field level coupling: This level maps to “Deck uses the internal of Card”. Namely, given two objects A and B, A modifies or references B’s fields directly.
  
• Method level coupling: This level maps to “Deck only uses the methods of Card, but…”. To move to this level, we create getters and setters for B’s fields and A uses those rather than accessing the fields directly. A still creates B directly using one of B’s constructors, and all references to instances of B are of type class B – this is know as having a reference to a concrete class.
  
• Constructor level coupling: This level maps to “Deck only sees Card via an interface…”. To move to this level, we create an interface I that B implements. After creating an instance of class B, A references that instance via the interface I. Class A however is still coupled to Class B via its constructor.
  
• API level coupling: This level maps to “Deck only sees IGenericCard and uses…”. To move to this level, we refactor the system using one or more creational patterns. A then uses the creational objects, such as factory or builder, to create an instance of B. A is now only coupled to B via the method signatures of interface I.
  
• Message level coupling: This level maps to “Deck communicates with Card via a message” (note: the last example I gave is a bit broad and covers the last three levels in the formal model). To move to this level, we refactor the system using the message oriented behavioral patterns such as adapter, command, mediator, an interpreter. At this level of coupling A has no direct or even inferred knowledge of B. A and B are only coupled via the messages A invokes and the messages B services. At this level of coupling, however, the message invocation system still ties A and B to the same language and processor by using a shared data structure to represent the message.
  
• Protocol level coupling: To move to this level, the messaging objects are refactored to introduce the concept of marshalling – that is where the message can be streamed out as protocol standard message. At this level, Object A can exist on a separate process implemented in different language than B. A and B are only coupled via the messaging protocol the messaging objects marshal to.
  
• There are additional levels of coupling beyond this one, but hopefully for now you get the idea
  

Notice how the more de-coupled the objects become, the more formal the overall system that the objects live in needs to become. For example, to move from constructor level coupling to language level coupling, you need to re-factor your system using one or more creational patterns (more on these in the next article) as a guide.
When deciding your coupling levels, you need to weigh the trade-offs. Rather than focusing on the benefit of going to the next loosest coupling level, focus instead on the consequence of staying at the coupling level you are at. If you are currently at Constructor level coupling, before you move to API level coupling ask yourself how many new types of objects will you be creating in this area of the system in the next 12 months? If the answer is a low number (in the 1-5) range, then you may never get the payback in that time period for incurring the cost of refactoring. However, as soon as you encounter a project that puts you over that ROI threshold, you should add the refactoring task into your plans.

Entry Filed under: Software Development