I wont say what "community" because I want a non-biased explanation, but let's say you're building a reusable module and that module requires 3+ dependent modules and removing 1 of them causes a breaking error not only in your app as a whole which uses this module, but the module itself.

From my understanding (which must be wrong) a loosely coupled modular system will not break by simply removing one module. The app should still run but without that "feature" / module and the module itself shouldn't causes everything to not run simply because a dependent module doesn't exist.

Is this wrong? If so, if modules are still dependent to the point of everything not working whats the difference between tight/loose coupling?

migrated from stackoverflow.com Feb 10 '12 at 16:42

This question came from our site for professional and enthusiast programmers.

  • 2
    This is somewhat like arguing you can remove the tires from a car and it will still work fine – Ryathal Feb 10 '12 at 16:51
  • 1
    @Ryathal - Well, it will actually :) The "car" will work fine. It won't have any tires but it will work fine. As a matter of fact, if you want you can ruin the wheels, but you can actually drive it too. Might be a little bumpy :) – Rook Feb 11 '12 at 10:01
  • Yes, exactly as @ldigas said. The car would start, radio would work, everything would work, but the movement part. Thats what I was trying to say. – Oscar Godson Feb 12 '12 at 1:03

Not quite --- removing the module could well break the system. The idea behind loosely coupled systems is that swapping in a completely different module will work just fine so long as the new module conforms to the same interface requirements as the old one. If it were tightly coupled, the surrounding code would make presumptions about the internals and would start to fail if a new module was introduced.

  • +1: Great answer! Modules must to depend on other modules, but not on their internal implementation. – Giorgio Feb 11 '12 at 9:41

Loose coupling is essentially the indirect dependency between module on how they can evolve.

Generally, when there is a tightly coupled systems different modules/objects have a very specific behaviors that assumes that behavior of the peripheral objects. Such objects are linked/coupled to other modules behaviors and they cannot be re-used in isolation or in any other context.

Such modules even though responsible for individual functionality cannot evolve independently or cannot evolve

An example:

Let's say you have 3 objects Shape (a model object) and Canvas (a UI element). Now

Assume that a method shape.draw(Canvas) will draw an object on the plane that is supplied by the plane of the canvas.

Now, sometimes windows are partially covered and are resized. In such cases, the above method might just do something like this.

shape::draw(Canvas) {
   Rect.WindowLeft = Canvas.GetWindowRect.getLeftOffset(); 
   Rect.LeftPixel = Canvas.GetWindowRect.pixels() + Rect.WindowLeft; 
   ....  // like this get all co-ordinates. 

   draw_instance(Rect);  // This will draw the actual shape. 

Basically, here the draw function picks up the rectangle where things needs to be drawn. This is easy to understand (people might call this simple) code. However, this is extremely coupled code.

Imagine the situation:

  • What if the canvas's mechanism of holding windows is no longer a rectangle?
  • what if there are additional offsets that Canvas keeps which is private?
  • What if some other application wants the same shape but no longer has a GUI window (for example, it is creating images and saving in files).

The root cause of the problem is that object shape knows and hence tightly coupled with Canvas.

What is desirable that a pixel set is given to shape where it writes; the shape should not have (even implicit) knowledge about where the pixels are actually written.


It depends, even on what you specify as module. Some parts of the system should be tightly coupled (for example, your entities should be reused across entire app), but some systems should be loose, either with interface separations, or if we are talking about not breaking the application if you remove the module, then that module must be wired up somehow dynamically, maybe through IoC container or something.

Also, tight coupling means that some part depends on specific module implementation, not the definition of module or something.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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