Zuma Lifeguard Wiki

Components should be designed to minimize coupling. The following aims to list tangible benefits of favoring the creation decoupled components.

Coupling, in general, is the degree to which each program module relies on each one of the other modules; "low coupling is often a sign of a well-structured computer system, and when combined with high cohesion, supports the general goals of high readability and maintainability."

Benefits of highly decoupled components[]

When a component is loosely coupled, it possesses the following benefits:

  • The component may be unit tested independently.
  • Static-code analysis tools (such as FxCop) can be more easily vdsdsfsdffsdfrun against it.
  • Code Coverage tools (such as Rational Pure Coverage) typically take a long time to instrument an entire application. By being able to run the component under a unit-test harness, Code Coverage tools will likely encounter fewer problems, if any.
  • Easier to work on the code outside of Source Control. One can actually copy the component on a local hard-disk and test it independently outside the build-environment
    • This has the additional benefit in that it's easier to outsource the work.
  • It's easier for new programmers to get up and running. They don't have to necessarily understand, or even execute, the entire system. As long as they can run the unit test, they can work on the component.
  • It's easier to work on bugs if it requires a complex scenario by which to execute the offending code. For instance, code related to object migration will require a fair amount of set up, especially for a new developer. If the code in question is already decoupled so that it can be executed independently of the rest of the system, then such code can be more easily debugged and fixed.

Loosely Coupled Services[]

Prefer loosely coupled services, and connect decoupled systems via some method of message-oriented middleware. This increases the flexibility of an architecture by enabling applications to exchange messages with other programs without waiting for them to consume or deliver data in real-time. The messages sent back and forth, containing formatted data and/or actions, are stored in some kind of a message queue that’s used between interoperability processes. So if the destination process is busy, the message is held in a temporary storage location until it can be processed. This type of service-oriented architectures tends to be:

  1. More flexible than RPC-based systems because implementations can work with both synchronous data, but be able to fall back to asynchronous communication if a server becomes unavailable.
  2. More supportable because the system is easier to interrogate, since the various services know how to throttle and thus retain a working state that can be diagnosed and debugged in real time.