|
|
This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (June 2008) |
| This article needs additional citations for verification. Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (July 2008) |
The notion of loose coupling is found in computer systems, and was introduced into organizational studies by Karl Weick. Sub-areas include the coupling of classes, interfaces, data, and services.
Contents |
Coupling refers to the degree of direct knowledge that one class has of another. This is not meant to be interpreted as encapsulation vs. non-encapsulation. It is not a reference to one class's knowledge of another class's attributes or implementation, but rather knowledge of that other class itself.
Strong coupling occurs when a dependent class contains a pointer directly to a concrete class which provides the required behavior. Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes. Loose coupling provides extensibility to designs. A new concrete class can easily be added later that implements that same interface without ever having to modify and recompile the dependent class. Strong coupling does not allow this.
This is a UML diagram (created in IBM Rhapsody) illustrating an example of loose coupling between a dependent class and a set of concrete classes, which provide the required behavior:
For comparison, this diagram illustrates the alternative design with strong coupling between the dependent class and a provider:
The degree of loose coupling can be measured by noting the number of changes in data elements that could occur in the sending or receiving systems and determining if the computers would still continue communicating correctly. These changes include items such as:
Loose coupling of interfaces can be dramatically enhanced when publishers of data transmit messages using a flexible file format such as XML to enable subscribers to publish clear definitions of how they subsequently use this data. For example, a subscriber could publish the collection of statements used to extract information from a publisher's messages by sharing the relevant XPath expressions used for data transformation. This would allow a responsible data publisher to test whether their subscriber's extraction methods would fail when a published format changes.
Loose coupling of services can be enhanced by reducing the information passed into a service to the key data. For example, a service that sends a letter is most reusable when just the customer identifier is passed and the customer address is obtained within the service. This decouples services because services do not need to be called in a specific order (e.g. GetCustomerAddress, SendLetter)
Note that loose coupling is not universally positive. If systems are de-coupled in time using Message-oriented middleware, it is difficult to also provide transactional integrity. Data replication across different systems provides loose coupling (in availability), but creates issues in maintaining synchronisation.
stock | retire | vm
Why are we here?
All text is available under the terms of the GNU Free Documentation License
This page is cache of Wikipedia. History