Coupling or dependency is the degree to which each program module relies on each one of the other modules.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine, original developer of Structured Design [1] was also an early proponent of these concepts (see also SSADM).

Types of coupling

Some types of coupling, in order of highest to lowest coupling, are as follows:
Content coupling (high):
Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module).
Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module.
Common coupling:
Common coupling is when two modules share the same global data (e.g. a global variable).
Changing the shared resource implies changing all the modules using it.
External coupling:
External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface.
Control coupling:
Control coupling is one module controlling the logic of another, by passing it information on what to do (e.g. passing a what-to-do flag).
Stamp coupling (Data-structured coupling):
Stamp coupling is when modules share a composite data structure and use only a part of it, possibly a different part (e.g. passing a whole record to a function which only needs one field of it).
This may lead to changing the way a module reads a record because a field, which the module doesn't need, has been modified.
Data coupling:
Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data which are shared (e.g. passing an integer to a function which computes a square root).
Message coupling (low):
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages (or events, see Message passing).
No coupling:
Modules do not communicate at all with one another.

Answered by Ashish Yadav , an ibibo Master, at 4:08 PM on September 11, 2008

In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine, original developer of Structured Design was also an early proponent of these concepts .
Coupling can be "low" or "high" . Low coupling refers to a relationship in which one module interacts with another module through a stable interface and does not need to be concerned with the other module's internal implementation . With low coupling, a change in one module will not require a change in the implementation of another module. 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.

Systems that do not exhibit low coupling might experience the following developmental difficulties:

Change in one module forces a ripple of changes in other modules.
Modules are difficult to understand in isolation.
Modules are difficult to reuse or test because dependent modules must be included.

Some types of coupling, in order of highest to lowest coupling, are as follows:

Content coupling (high)
Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module).
Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module.

PLEASE VISIT THE SOURCE SITE FOR MORE DETAILS :http://en.wikipedia.org/wiki/ Coupling_(computer_science)

Answered by Sanya Tahir , an ibibo Master, at 12:06 PM on September 06, 2008

Well , coupling or dependency is the degree to which each program module relies on each one of the other modules.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine, original developer of Structured Design was also an early proponent of these concepts

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Low coupling refers to a relationship in which one module interacts with another module through a stable interface and does not need to be concerned with the other module's internal implementation (see Information Hiding). With low coupling, a change in one module will not require a change in the implementation of another module. 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.

Systems that do not exhibit low coupling might experience the following developmental difficulties:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

The concept of coupling is usually related to the concept of cohesion: low coupling facilitates high cohesion, and vice versa. For example, one approach to increasing cohesion is functional design, which seeks to limit the responsibilities of modules along functionally-related boundaries. Modules with single responsibilities tend to communicate less with other modules, which typically causes the side-effect of reduced coupling. This can also be seen in object-oriented programming, where coherence is said to increase when classes are re-factored to contain more closely-related code. This tends to cause the connections between the classes to become less dependent on their internal implementations, which results in reduced coupling. Specifically, coupling increases between two classes A and B if:

* A has an attribute that refers to (is of type) B.
* A calls on services of an object B.
* A has a method which references B (via return type or parameter).
* A is a subclass of (or implements) class B.

Low coupling may also reduce performance, and a highly-coupled system is sometimes desirable to achieve maximum efficiency. Regardless, in many modern computing systems, the cost of reduced performance is often seen as a worthy trade for the benefits to the software development process that result from low coupling.

For more details , Please visit the source site :

http://en.wikipedia.org/wiki/C oupling_(computer_science)

Answered by Alok Gupta , an ibibo Guru, at 12:56 AM on September 06, 2008

In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine, original developer of Structured Design
http://www.answers.com/topic /coupling-computer-science

Answered by Nishu's , an ibibo Master, at 10:22 PM on September 05, 2008

In computer science, coupling is considered to be the degree to which each program module relies on other modules, and is also the term used to describe connecting two or more systems. Coupling is broken down into loose coupling, tight coupling, and decoupled. Coupling is also used to describe software as well as systems. Also called dependency.

There are various types of couplings: http://www.answers.com/topic/c oupling-computer-science

Answered by Keshto Patel , an ibibo Master, at 8:14 PM on September 05, 2008

Hello ..

Coupling or dependency is the degree to which each program module relies on each one of the other modules.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine, original developer of Structured Design [1] was also an early proponent of these concepts (see also SSADM).

Types of coupling

Some types of coupling, in order of highest to lowest coupling, are as follows:
Content coupling (high):
Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module).
Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module.
Common coupling:
Common coupling is when two modules share the same global data (e.g. a global variable).
Changing the shared resource implies changing all the modules using it.
External coupling:
External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface.
Control coupling:
Control coupling is one module controlling the logic of another, by passing it information on what to do (e.g. passing a what-to-do flag).
Stamp coupling (Data-structured coupling):
Stamp coupling is when modules share a composite data structure and use only a part of it, possibly a different part (e.g. passing a whole record to a function which only needs one field of it).
This may lead to changing the way a module reads a record because a field, which the module doesn't need, has been modified.
Data coupling:
Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data which are shared (e.g. passing an integer to a function which computes a square root).
Message coupling (low):
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages (or events, see Message passing).
No coupling:
Modules do not communicate at all with one another.

Answered by Saq , an ibibo Specialist, at 8:04 PM on September 05, 2008