Talk:Loose coupling

Very early comments (July 2005 - January 2007)

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

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?

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?

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)

Yes. I think we should make this article be just about loose coupling in computing, since that is what the vast majority of the article is about. We could create a page called something like Loose coupling (disambiguation) that says something like the following

Loose coupling describes the way components of a system are related. It may mean:

• Loose coupling in computing, where each of the software components has, or makes use of, little or no knowledge of the definitions of other components.
• Loose coupling (organisations), where ties between people and groups in an organisation are not as strong as those recognised by theories of bureaucracy.
• Loose coupling in electronics, where an inductively coupled circuit with a low coupling coefficient.

Yaris678 (talk) 07:03, 11 September 2014 (UTC)

Actually, Weick seems to be the main source out there on loose coupling in organisations, having written quite a lot about it and being cited and quoted frequently. Maybe, at least in the short term, the best disambig page would be more like this:

Loose coupling describes the way components of a system are related. It may mean:

• Loose coupling in computing, where each of the software components has, or makes use of, little or no knowledge of the definitions of other components.
• Loose coupling in organisations, where ties between people and groups in an organisation are not as strong as those recognised by theories of bureaucracy. A model developed by Karl E. Weick.
• Loose coupling in electronics, where an inductively coupled circuit with a low coupling coefficient.

Yaris678 (talk) 08:56, 9 December 2014 (UTC)

I have created Loose coupling (disambiguation). It is similar, but not identical, to the above. Yaris678 (talk) 15:12, 9 December 2014 (UTC)

Earlier reference

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

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."

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)

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

To not merge on the grounds of overlapping but distinct scope, with unopposed ideas for improvement. Klbrain (talk) 07:15, 19 October 2020 (UTC)

---

I propose to merge Orthogonality (programming) into Loose coupling. These articles explain essentially the same concept. Proposing a merger in this direction because "loose coupling" seems somewhat wider recognizable term for me (orthogonality is the neologism of "The Pragmatic Programming" book) and because Loose coupling seems to be more developed at the moment. Leventov (talk) 07:43, 3 March 2020 (UTC)

Also Orthogonality#Computer_science, which should at least be merged into Orthogonality (programming). Leventov (talk) 10:34, 21 March 2020 (UTC)

• Oppose Orthogonality is a set index article, so it needs a section on the use in computer science. It may be shorter than it is, but some duplication of content is normal in these cases. I also oppose merging orthogonality (programming) to loose coupling. Orthogonality is characterized by lack of interaction, whereas a loose coupling is still a coupling, i. e. components do interact.

Merging loose coupling to coupling (computer programming) might make sense, though. Paradoctor (talk) 12:25, 21 March 2020 (UTC)

• I guess there are two meanings of the term "orthogonality" combined in Orthogonality (programming). One is more narrow, like orthogonality of an instruction set (akin to geometric orthogonality). Another is a broader software sense, from Thomas & Hunt's book "The Pragmatic Programmer". I would say the latter one really doesn't mean "lack of interaction" it means "if I change part of program A, I don't have to change part of program B". Whether this is due to "lack of interaction" or "loose coupling" can be a topic for research, but I would say not in Wikipedia. Thomas & Hunt don't cover this in "The Pragmatic Programmer", as far as I remember. Therefore, I propose to leave orthogonality (programming), narrow its focus on programming languages and instruction sets, and a section "Use in The Pragmatic Programmer book". Leventov (talk) 07:08, 28 April 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Example: Hyperlink

As an example, so that the concept is easier to understand, is it correct to call a hyperlink a loose coupling? Bjornte (talk) 08:19, 17 January 2022 (UTC)