Talk:Loose coupling

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Attribution footnote: The paragraph beginning "In a more open definition ..." added 5th May 2005 is based on the Loosely Coupled website's definition of loose coupling [1].


I am unsettled by the claim that this suggestion reduces coupling: "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."

This seems to me to make the coupling tighter: instead of being bound by an interface specification, we now ask the publisher to be aware of internal details of the subscriber (the XPath expressions).

Yeah, I totally agree. That example doubles the existing coupling. Examples of how to actually decouple systems are, however, often hairy... Perhaps some hand-waving about adding a level of indirection, or applying a Design Pattern. Decoupling simply involves shifting dependencies between two or more modules to other parts of the system, so there's no "magic formula" to "decouple" a system (unless the existent coupling was arbitrarily & unnecessarily implemented, like the current example...!)

One of the examples of methods for reducing coupling seems exactly false. It says: "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)" This example would serve to increase coupling, as the user of a service is now coupled to the internal database, or some separate database, of customer addresses. The consumer and the user would actually be more loosely coupled if the entire address were sent with the request to send the letter. The point about calling services in a specific order relates to whether the interface is stateless, not whether it is loosely coupled. It also references the concept of reusability. While reusability is relevant to good service design, and is often a consequence of loose coupling, it is a separate concept from loose coupling.

I recommend removing the example cited from the page. --DelRayVA192.31.106.36 18:39, 3 January 2007 (UTC)

refererence to Weick's 1982-paper could not be found[edit]

In the current article on "Loose coupling" a quote on Weick reads:

Karl Weick's major contribution to the topic of loose coupling in an organizational context comes from his 1982 paper on "The Management of Change among Loosely Coupled Elements", which is reprinted in "Making Sense of the Organization" (Blackwell, 2000).

Now in Karl Weick's own cv ([2]) this 1982-paper has not been mentioned. Is Karl's own cv incomplete or is e.g. one of the following titles meant:

108. Organizational change in loosely coupled systems. Ohio State University, October 16, 1981.
43. The concept of loose coupling: An assessment. Dialogue, American Educational Research Association, December 1986, 8-11.
51. Loose coupling: Beyond the metaphor. Current Contents (Citation Classic), 1989, 21(12), 14.
52. The nature of loose coupling. School of Education, Stanford University, November 14, 1976.
19. Educational organizations as loosely coupled systems. Administrative Science Quarterly, 1976, 21, 1-19. Reprinted ...

Martin Op 't Land 08:58, 16 March 2007 (UTC)

The correct reference is as follows. Weick, K.E. (1982), "Management of Organizational Change Among Loosely Coupled Elements", in Goodman, P.S., Associates (Eds),Change in Organizations, Jossey-Bass, San Francisco, CA, pp.375-408. ISBN 0875895476. It is reprinted in my copy of Making Sense of the Organization (and other people have also referenced this version [3]) but for some reason it is not listed among the contents on the publisher's website - so perhaps it has been dropped from the current edition. --RichardVeryard 09:27, 19 March 2007 (UTC)


Alternate definition?[edit]

The following was proffered as an alternative definition of loose coupling:

Loose coupling also describes a computer system where two or more physical processors are sharing storage disks with each other in a real time environment. The system must be designed such that the code to be shared is reentrant and that the records to be shared are protected by record locking.

More properly, this section should be renamed "An Implementation of Loose Coupling". I plan to make this change the next time around here, unless someone beats me to it. Vonkje 21:57, 5 May 2007 (UTC)

Split?[edit]

The article as it stands is a mismatch of coupling related to business & management and coupling related to computing. IMO it should be disambiguated and split. There is already a CS article on coupling, and it even has a section on Low coupling, although this appears to be subtly different. --BlueNovember (talk contribs) 11:38, 24 May 2009 (UTC)

Earlier reference[edit]

I've found reference to loose coupling (in an organisational context) in an earlier text than that mentioned by Weick. Examples:

"..we require a theory of organizational choice that recognizes the loose coupling" (between individuals' actions, and values, organizations' actions, environmental responses) (p. 14)
(In a choice situation, underpinned by ambiguity) "What happens is often the almost fortuitous result of the intermeshing of loosely-coupled processes." (p. 26)
Book ref: March, J. G., Olsen, J. P. (1976) Ambiguity and choice in organizations. Bergen: Universitetsforlaget

Not having read Weick's paper, I don't know if he referenced March & Olsen - but M&O's phrasing certainly seems significant to the origins of this term. Cormaggio is learning 07:39, 19 June 2009 (UTC)

Opposite[edit]

Shouldn't the opposite of loose coupling be tight coupling? Loose-tight, weak-strong. —Preceding unsigned comment added by 217.194.34.103 (talk) 19:22, 22 March 2010 (UTC)

"Coupling refers to the degree of direct knowledge that one class has of another."[edit]

This is the lead definition in the article:

  "Coupling refers to the degree of direct knowledge that one class has of another." 

Really? Class coupling is the --ONLY-- way to describe coupling in computing? Maybe we should all go back to assembly programming and not have to worry about coupling at all.

This article misses many significant concepts involved in coupling. —Preceding unsigned comment added by 151.193.220.28 (talk) 13:46, 2 April 2010 (UTC)