I am familiar with the term "highly coupled" but am curious if there are signs (code smells) that can indicate that code is highly coupled. I'm currently working with Java EE but this can apply to any language.


In case anyone's interested, this article sounds helpful: In pursuit of code quality: Beware the tight couple! (IBM)

  • 1
    Rule of thumb: If you make a small change, hit compile, and have time to go to the bathroom, it's too tightly coupled.
    – Uri
    Feb 12, 2011 at 1:45

9 Answers 9


The number one indicator of badly coupled modules in my opinion is bilateral dependencies. For example, Module1 one calls some function in Module2 and Module2 calls some function in Module1.

Most interfaces should be unidirectional. If the module that was called needs to pass some information to the calling module that is not returned as part of the call then it should use some sort of message passing or event triggering mechanism such as a message queue. Ideally, the handle to message passing interface should be passed in during some initialization or registration process. This completely abstracts the interface in such a way that the module does not actually care who the event is for...hence it is decoupled.

Another indication is when one module is constantly calling some other module for some specific data set. This should make you question who should actually own the data set. Why is it that this module in question always needs to see data that belongs to some other module?

A third tool so to speak is to ask yourself, "Can I pull this module out and replace it without requiring changes to other modules.

This is by no means a exhaustive list, but they are the top three things I ask myself when designing software.

  • 2
    +1 for bilateral dependencies. They the dark heart of pure evil. Feb 11, 2011 at 20:34

The old design saying is, "You can touch your friends, and you can touch your privates. But you can't touch your friends privates." That's coupling in a nutshell.

Signs of highly coupled code include very large interfaces that let people know about private details of the implementation, and objects that seem to "know a lot about each other". There are tools for automatic analysis that will flag code that looks tightly coupled for you. See http://www.scitools.com/features/metricsintro.php for a random one. (I have no idea how well it works. It just turned up fairly high in a Google search.)


Try writing some unit tests for classes. If you can't easily test classes without the need to create/mock loads of support classes or a db/ui whatever then it's a sure sign of bad coupling/dependencies.

It's also one of the best cures, but you have to do it during the coding (like TDD) to keep you honest.

  • +1. My favorite peeve is not being able to instantiate the business object on it's own AND validate all of it's own business rules. Typically one sees a "value required" rule, for example, implemented in the client UI but not in the object itself. It's fine to put it in the UI (for performance considerations, let's say) but it MUST be in business object itself.
    – radarbob
    Apr 30, 2012 at 13:55

The obvious sign to me is that everything is public.

The other sign is Law of Demeter violations -- excessive this.SomeObj.SomeProp.SomeProp references on non-fluent interfaces.

I once saw what I've since dubbed a "puppetmaster class" that built a data entry form on-the-fly. It had several other software design violations so excessive coupling was the least of its concerns.

When it retrieving data from the controls it created, it did so like this:

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */
  • Wow. You created it, and it's null??????
    – Michael K
    Feb 11, 2011 at 20:22
  • It could've been a different type. That was just one of many in a loop. Feb 11, 2011 at 20:28

The Ripple Effect.

Every change has a ripple effect through all the tightly-coupled modules.

The "Open-Closed" principle has been violated in that it's not properly closed and change leaks out.

  • +1 for Ripple. Working with tightly-coupled monstrosities makes me want to reach for the Ripple. Feb 11, 2011 at 20:35
  • @Adam Crossland: I didn't the the Laphroaig Effect would work well -- too pricey. But the Thunderbird Effect might have been good.
    – S.Lott
    Feb 11, 2011 at 20:37

Check the number of #include/imports etc between classes/packages/dlls/jars/whatnots. Try to draw a graph of this, mentally, manually or using some kind of tool.

  • If that graph is dense (i.e. many connections all over the place), then your system is monolithic and highly coupled.
  • If it's clearly divided into layers, with no connections across/trough layers, and the connections are few, you have a modular and decoupled system.

If you find it impossible to implement a feature because you have no idea where a specific responsibility goes, then your system is too tightly coupled.


For very basic signs you may consider looking the number of interfaces and their usage between classes of different packages(usually loosely-coupled code contains interfaces and there are limited direct interaction between the individual classes in different packages), number of class names that can be used to group other classes (in loosely-coupled code actual interaction between classes that have different jobs are done by interface functions or by functions of more common/grouping classes) or number public variables inside classes(more loosely much lesser/ even none public variables).


Pretty much all the code smells indicate superfluous coupling in some manner. I suppose the smell that would most indicate coupling though might be "Inappropriate Intimacy" (my favorite smell).

I suppose another reasonable method to measure would be to count the lines in your UML diagram. If you have N objects, and N^N (or more) lines between them, then your code is pretty much maximally coupled. N lines would probably be about as minimal as you could get.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.