blocks|key|1240881|text|定义|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1240882|本质上，耦合是指一个给定的对象或一组对象在多大程度上依赖于另一对象或另一组对象来完成其任务。|1240883|高耦合|1240884|想想一辆车。为了使发动机启动，必须插入一个钥匙进入点火，转动，汽油必须存在，火花必须发生，活塞必须点火，发动机必须生机勃勃。你可以说汽车发动机和其他几个物体高度耦合。这是高度耦合，但这并不是一件坏事。|1240885|松耦合|1240886|想象一下网页的用户控件，它负责允许用户发布、编辑和查看某些类型的信息。单个控件可用于让用户发布新的信息或编辑新的信息。控件应该能够在两个不同的路径之间共享-新路径和编辑路径。如果控件的编写方式使其需要来自包含控件的页面的某种类型的数据，那么您可以说它的耦合程度太高了。控件不应该需要来自其容器页的任何内容。|1240887|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

<h2>Definition</h2>

Essentially, coupling is how much a given object or set of object relies on another object or another set of objects in order to accomplish its task.

<h2>High Coupling</h2>

Think of a car. In order for the engine to start, a key must be inserted into the ignition, turned, gasoline must be present, a spark must occur, pistons must fire, and the engine must come alive. You could say that a car engine is highly coupled to several other objects. This is high coupling, but it's not really a bad thing.

<h2>Loose Coupling</h2>

Think of a user control for a web page that is responsible for allowing users to post, edit, and view some type of information. The single control could be used to let a user post a new piece of information or edit a new piece of information. The control should be able to be shared between two different paths - new and edit. If the control is written in such a way that it needs some type of data from the pages that will contain it, then you could say it's too highly coupled. The control should not need anything from its container page.

blocks|key|887517|text|松散耦合，通常是两个行为者在相同的工作负载上相互独立工作。因此，如果有两个web服务器使用相同的后端数据库，那么您会说这些web服务器是松散耦合的。紧密耦合的例子是在一个web服务器上有两个处理器.这些处理器是紧密耦合的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|887518|希望这有点帮助。|887519|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Loose coupling, in general, is 2 actors working independently of each other on the same workload. So if you had 2 web servers using the same back-end database, then you would say that those web servers are loosely coupled. Tight coupling would be exemplified by having 2 processors on one web server... those processors are tightly coupled.

Hope that's somewhat helpful.

blocks|key|1240967|text|对不起，但是“松散耦合”不是编码问题，而是设计问题。“松散耦合”一词与“高衔接”的理想状态密切相关，它是相对的，但又是互补的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1240968|松散耦合仅仅意味着单独的设计元素应该被构造，这样就减少了他们需要知道的关于其他设计元素的不必要信息的数量。|1240969|高内聚力有点像“紧密耦合”，但是高衔接是一种状态，在这种状态下，真正需要了解彼此的设计元素被设计出来，这样它们就能干净利落地工作在一起。|1240970|关键是，一些设计元素应该知道其他设计元素的细节，所以它们应该是这样设计的，而不是偶然的。其他设计元素不应该知道其他设计元素的细节，所以它们应该是有目的的，而不是随机的。|1240971|实现这一点留给读者练习:)。|1240972|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Sorry, but "loose coupling" is not a coding issue, it's a design issue. The term "loose coupling" is intimately related to the desirable state of "high cohesion", being opposite but complementary.

Loose coupling simply means that individual design elements should be constructed so the amount of unnecessary information they need to know about other design elements are reduced.

High cohesion is sort of like "tight coupling", but high cohesion is a state where design elements that really need to know about each other are designed so that they work together cleanly and elegantly.

The point is, some design elements should know details about other design elements, so they should be designed that way, and not accidentally. Other design elements should not know details about other design elements, so they should be designed that way, purposefully, instead of randomly.

Implementing this is left as an exercise for the reader :) .

blocks|key|1241076|text|紧密耦合的代码依赖于具体的实现。如果我需要在我的代码中列出字符串，并按如下方式声明(在Java中)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1241077|ArrayList<String>+myList+=+new+ArrayList<String>();|code-block|syntax|javascript|1241078|然后我就依赖于ArrayList实现。|1241079|如果要将其更改为松散耦合的代码，则将引用改为接口(或其他抽象)类型。|1241080|List<String>+myList+=+new+ArrayList<String>();|1241081|这使我无法在myList上调用特定于ArrayList实现的任何方法。我仅限于列表接口中定义的那些方法。如果我后来决定我真的需要一个LinkedList，我只需要在一个地方修改我的代码，在那里我创建了新的列表，而不是在我调用ArrayList方法的100个地方。|offset|length|style|CODE|1241082|当然，您可以使用第一个声明实例化ArrayList，并限制自己不使用任何不是List接口一部分的方法，但是使用第二个声明使编译器保持诚实。|1241083|entityMap^0|0|0|0|0|0|6|6|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|10|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|11|8|@$O|12|P|13|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Tightly coupled code relies on a concrete implementation. If I need a list of strings in my code and I declare it like this (in Java)

<pre><code>ArrayList&lt;String&gt; myList = new ArrayList&lt;String&gt;();
</code></pre>

then I'm dependent on the ArrayList implementation.

If I want to change that to loosely coupled code, I make my reference an interface (or other abstract) type.

<pre><code>List&lt;String&gt; myList = new ArrayList&lt;String&gt;();
</code></pre>

This prevents me from calling any method on <code>myList</code> that's specific to the ArrayList implementation. I'm limited to only those methods defined in the List interface. If I decide later that I really need a LinkedList, I only need to change my code in one place, where I created the new List, and not in 100 places where I made calls to ArrayList methods.

Of course, you can instantiate an ArrayList using the first declaration and restrain yourself from not using any methods that aren't part of the List interface, but using the second declaration makes the compiler keep you honest.

blocks|key|1241168|text|您可以更多地了解“松耦合”的一般概念。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1241169|简而言之，它描述了两个类之间的关系，其中每个类对另一个类的了解最少，并且每个类都可能继续很好地工作，不管另一个类是否存在，并且不依赖于另一个类的特定实现。|1241170|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Loose_coupling^0|8|5|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

You can read more about the generic concept of <a href="http://en.wikipedia.org/wiki/Loose_coupling" rel="nofollow noreferrer">"loose coupling"</a>.

In short, it's a description of a relationship between two classes, where each class knows the very least about the other and each class could potentially continue to work just fine whether the other is present or not and without dependency on the particular implementation of the other class.

blocks|key|242223|text|我将以Java为例。假设我们有一个类似这样的类：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|242224|public+class+ABC
{
+++public+void+doDiskAccess()+{...}
}|code-block|syntax|javascript|242225|当我打电话给全班时，我需要这样做：|242226|ABC+abc+=+new+ABC();

abc.+doDiskAccess();|242227|到现在为止还好。现在假设我还有一个类似于这样的类：|242228|public+class+XYZ
{
+++public+void+doNetworkAccess()+{...}
}|242229|它看起来和ABC完全一样，但是假设它在网络上工作，而不是在磁盘上工作。现在让我们编写一个这样的程序：|242230|if(config.isNetwork())+new+XYZ().doNetworkAccess();
else+new+ABC().doDiskAccess();|242231|这很管用，但有点笨重。我可以用这样的接口来简化这个过程：|242232|public+interface+Runnable
{
++++public+void+run();
}

public+class+ABC+implements+Runnable
{
+++public+void+run()+{...}
}

public+class+XYZ+implements+Runnable
{
+++public+void+run()+{...}
}|242233|现在我的代码可以如下所示：|242234|Runnable+obj+=+config.isNetwork()+?+new+XYZ()+:+new+ABC();

obj.run();|242235|看看有多少更干净和更简单的理解是什么？我们刚刚理解了松耦合的第一个基本原则:抽象。这里的关键是确保ABC和XYZ不依赖于调用它们的类的任何方法或变量。这允许ABC和XYZ是完全独立的API。换句话说，它们与父类“解耦”或“松散耦合”。|242236|但如果我们需要两个人之间的沟通呢？那么，我们可以使用进一步的抽象(比如事件模型+)来确保父代码永远不需要与您创建的API相结合。|offset|length|242237|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Event_model^0|0|0|0|0|0|0|0|0|0|0|0|0|0|Z|4|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1F|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1G|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1H|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1I|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1J|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1L|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1M|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1N|8|@]|9|@]|A|$E|F]]|$1|W|3|X|5|6|7|1O|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|10|3|11|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1R|8|@]|9|@$14|1S|15|1T|1|1U]]|A|$]]|$1|16|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]]]

I'll use Java as an example. Let's say we have a class that looks like this:

<pre><code>public class ABC
{
 public void doDiskAccess() {...}
}
</code></pre>

When I call the class, I'll need to do something like this:

<pre><code>ABC abc = new ABC();

abc. doDiskAccess();
</code></pre>

So far, so good. Now let's say I have another class that looks like this:

<pre><code>public class XYZ
{
 public void doNetworkAccess() {...}
}
</code></pre>

It looks exactly the same as ABC, but let's say it works over the network instead of on disk. So now let's write a program like this:

<pre><code>if(config.isNetwork()) new XYZ().doNetworkAccess();
else new ABC().doDiskAccess();
</code></pre>

That works, but it's a bit unwieldy. I could simplify this with an interface like this:

<pre><code>public interface Runnable
{
 public void run();
}

public class ABC implements Runnable
{
 public void run() {...}
}

public class XYZ implements Runnable
{
 public void run() {...}
}
</code></pre>

Now my code can look like this:

<pre><code>Runnable obj = config.isNetwork() ? new XYZ() : new ABC();

obj.run();
</code></pre>

See how much cleaner and simpler to understand that is? We've just understood the first basic tenet of loose coupling: abstraction. The key from here is to ensure that ABC and XYZ do not depend on any methods or variables of the classes that call them. That allows ABC and XYZ to be completely independent APIs. Or in other words, they are "decoupled" or "loosely coupled" from the parent classes.

But what if we need communication between the two? Well, then we can use further abstractions like an <a href="http://en.wikipedia.org/wiki/Event_model" rel="noreferrer">Event Model</a> to ensure that the parent code never needs to couple with the APIs you have created.

blocks|key|1241263|text|您可以认为(紧密或松散)耦合实际上是将特定类与其对另一个类的依赖分离所需的工作量。例如，如果类中的每个方法在底部都有一个小块，调用Log4Net来记录某些内容，那么您可以说您的类与Log4Net紧密耦合。如果您的类包含一个名为LogSomething的私有方法，它是唯一调用Log4Net组件的地方(其他方法都称为LogSomething+)，那么您会说类松散地耦合到Log4Net+(因为提取Log4Net并用其他方法替换它不需要花费太多的精力)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1241264|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You can think of (tight or loose) coupling as being literally the amount of effort it would take you to separate a particular class from its reliance on another class. For example, if every method in your class had a little finally block at the bottom where you made a call to Log4Net to log something, then you would say your class was tightly coupled to Log4Net. If your class instead contained a private method named LogSomething which was the only place that called the Log4Net component (and the other methods all called LogSomething instead), then you would say your class was loosely coupled to Log4Net (because it wouldn't take much effort to pull Log4Net out and replace it with something else).

blocks|key|242327|text|这是一个相当普遍的概念，所以代码示例不会给出整个情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|242328|一位工作人员对我说，“模式就像分形，当你放大到非常近的时候，当你放大到架构层面时，你就可以看到它们。”|242329|阅读简短的维基百科页面可以让你感觉到这种概括性：|242330|联轴器|offset|length|242331|就特定的代码示例而言..。|242332|下面是我最近工作过的一个松耦合，来自Microsoft.Practices.CompositeUI。|242333|++++[ServiceDependency]
++++public+ICustomizableGridService+CustomizableGridService
++++{
++++++++protected+get+{+return+_customizableGridService;+}
++++++++set+{+_customizableGridService+=+value;+}
++++}|code-block|syntax|javascript|242334|此代码声明该类依赖于CustomizableGridService。它不只是直接引用服务的确切实现，而是简单地声明它需要该服务的一些实现。然后，在运行时，系统解决该依赖。|242335|如果还不清楚，您可以在这里阅读更详细的说明：|242336|注入|242337|想象一下，ABCCustomizableGridService是我打算在这里连接的内容。|242338|如果我选择这样做，我可以拔出它，用XYZCustomizableGridService替换它，或者完全不改变这个依赖项的类的StubCustomizableGridService。|242339|如果我直接引用了ABCCustomizableGridService，那么我需要对该/那些引用/s进行更改，以便在另一个服务实现中进行交换。|242340|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Loose_coupling|1|http://en.wikipedia.org/wiki/Dependency_injection^0|0|0|0|0|3|0|0|0|0|0|0|0|0|2|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1F|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1G|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1H|8|@]|9|@$H|1I|I|1J|1|1K]]|A|$]]|$1|J|3|K|5|6|7|1L|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1M|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1N|8|@]|9|@]|A|$Q|R]]|$1|S|3|T|5|6|7|1O|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1P|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1Q|8|@]|9|@$H|1R|I|1S|1|1T]]|A|$]]|$1|Y|3|Z|5|6|7|1U|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1V|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1W|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]|1C|$5|17|18|19|A|$1A|1D]]]]

It's a pretty general concept, so code examples are not going to give the whole picture.

One guy here at work said to me, "patterns are like fractals, you can see them when you zoom in really close, and when you zoom way out to the architecture level."

Reading the brief wikipedia page can give you a sense of this generalness:

<a href="http://en.wikipedia.org/wiki/Loose_coupling" rel="noreferrer">http://en.wikipedia.org/wiki/Loose_coupling</a>

As far as a specific code example...

Here's one loose coupling I've worked with recently, from the Microsoft.Practices.CompositeUI stuff.

<pre><code> [ServiceDependency]
 public ICustomizableGridService CustomizableGridService
 {
 protected get { return _customizableGridService; }
 set { _customizableGridService = value; }
 }
</code></pre>

This code is declaring that this class has a dependency on a CustomizableGridService. Instead of just directly referencing the exact implementation of the service, it simply states that it requires SOME implementation of that service. Then at runtime, the system resolves that dependency.

If that's not clear, you can read a more detailed explanation here:

<a href="http://en.wikipedia.org/wiki/Dependency_injection" rel="noreferrer">http://en.wikipedia.org/wiki/Dependency_injection</a>

Imagine that ABCCustomizableGridService is the imlpementation I intend to hook up here.

If I choose to, I can yank that out and replace it with XYZCustomizableGridService, or StubCustomizableGridService with no change at all to the class with this dependency.

If I had directly referenced ABCCustomizableGridService, then I would need to make changes to that/those reference/s in order to swap in another service implementation.

blocks|key|887702|text|考虑一个简单的购物车应用程序，它使用CartContents类来跟踪购物车中的项目，并使用Order类来处理采购。Order需要确定购物车中内容的总价值，它可以这样做：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|887703|紧耦合示例：|BOLD|887704|public+class+CartEntry
{
++++public+float+Price;
++++public+int+Quantity;
}

public+class+CartContents
{
++++public+CartEntry[]+items;
}

public+class+Order
{
++++private+CartContents+cart;
++++private+float+salesTax;

++++public+Order(CartContents+cart,+float+salesTax)
++++{
++++++++this.cart+=+cart;
++++++++this.salesTax+=+salesTax;
++++}

++++public+float+OrderTotal()
++++{
++++++++float+cartTotal+=+0;
++++++++for+(int+i+=+0;+i+<+cart.items.Length;+i%2B%2B)
++++++++{
++++++++++++cartTotal+%2B=+cart.items[i].Price+*+cart.items[i].Quantity;
++++++++}
++++++++cartTotal+%2B=+cartTotal*salesTax;
++++++++return+cartTotal;
++++}
}|code-block|syntax|javascript|887705|注意OrderTotal方法(以及Order类)是如何依赖于CartContents和CartEntry类的实现细节的。如果我们试图改变这种逻辑，以允许折扣，我们很可能必须改变所有三个类别。此外，如果我们更改为使用List<CartEntry>集合来跟踪这些项，则还必须更改Order类。|887706|现在，有一个稍微好一点的方法来做同样的事情：|887707|弱耦合示例：|887708|public+class+CartEntry
{
++++public+float+Price;
++++public+int+Quantity;

++++public+float+GetLineItemTotal()
++++{
++++++++return+Price+*+Quantity;
++++}
}

public+class+CartContents
{
++++public+CartEntry[]+items;

++++public+float+GetCartItemsTotal()
++++{
++++++++float+cartTotal+=+0;
++++++++foreach+(CartEntry+item+in+items)
++++++++{
++++++++++++cartTotal+%2B=+item.GetLineItemTotal();
++++++++}
++++++++return+cartTotal;
++++}
}

public+class+Order
{
++++private+CartContents+cart;
++++private+float+salesTax;

++++public+Order(CartContents+cart,+float+salesTax)
++++{
++++++++this.cart+=+cart;
++++++++this.salesTax+=+salesTax;
++++}

++++public+float+OrderTotal()
++++{
++++++++return+cart.GetCartItemsTotal()+*+(1.0f+%2B+salesTax);
++++}
}|887709|特定于cart行项或cart集合或order的实现的逻辑仅限于该类。因此，我们可以更改任何这些类的实现，而不必更改其他类。我们可以通过改进设计、引入接口等方式进一步实现这种脱钩，但我认为您明白这一点。|887710|entityMap^0|I|C|19|5|1L|5|0|0|6|0|0|2|A|U|C|17|9|2Z|F|3T|5|0|0|0|6|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|16|8|@$9|17|A|18|B|H]]|D|@]|E|$]]|$1|I|3|J|5|K|7|19|8|@]|D|@]|E|$L|M]]|$1|N|3|O|5|6|7|1A|8|@$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1L|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1M|8|@$9|1N|A|1O|B|H]]|D|@]|E|$]]|$1|T|3|U|5|K|7|1P|8|@]|D|@]|E|$L|M]]|$1|V|3|W|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1R|8|@]|D|@]|E|$]]]|Y|$]]

Consider a simple shopping cart application that uses a <code>CartContents</code> class to keep track of the items in the shopping cart and an <code>Order</code> class for processing a purchase. The <code>Order</code> needs to determine the total value of the contents in the cart, it might do that like so:
Tightly Coupled Example:
<pre class="lang-cs prettyprint-override"><code>public class CartEntry
{
 public float Price;
 public int Quantity;
}

public class CartContents
{
 public CartEntry[] items;
}

public class Order
{
 private CartContents cart;
 private float salesTax;

 public Order(CartContents cart, float salesTax)
 {
 this.cart = cart;
 this.salesTax = salesTax;
 }

 public float OrderTotal()
 {
 float cartTotal = 0;
 for (int i = 0; i &lt; cart.items.Length; i++)
 {
 cartTotal += cart.items[i].Price * cart.items[i].Quantity;
 }
 cartTotal += cartTotal*salesTax;
 return cartTotal;
 }
}
</code></pre>
Notice how the <code>OrderTotal</code> method (and thus the Order class) depends on the implementation details of the <code>CartContents</code> and the <code>CartEntry</code> classes. If we were to try to change this logic to allow for discounts, we'd likely have to change all 3 classes. Also, if we change to using a <code>List&lt;CartEntry&gt;</code> collection to keep track of the items we'd have to change the <code>Order</code> class as well.
Now here's a slightly better way to do the same thing:
Less Coupled Example:
<pre class="lang-cs prettyprint-override"><code>public class CartEntry
{
 public float Price;
 public int Quantity;

 public float GetLineItemTotal()
 {
 return Price * Quantity;
 }
}

public class CartContents
{
 public CartEntry[] items;

 public float GetCartItemsTotal()
 {
 float cartTotal = 0;
 foreach (CartEntry item in items)
 {
 cartTotal += item.GetLineItemTotal();
 }
 return cartTotal;
 }
}

public class Order
{
 private CartContents cart;
 private float salesTax;

 public Order(CartContents cart, float salesTax)
 {
 this.cart = cart;
 this.salesTax = salesTax;
 }

 public float OrderTotal()
 {
 return cart.GetCartItemsTotal() * (1.0f + salesTax);
 }
}
</code></pre>
The logic that is specific to the implementation of the cart line item or the cart collection or the order is restricted to just that class. So we could change the implementation of any of these classes without having to change the other classes. We could take this decoupling yet further by improving the design, introducing interfaces, etc, but I think you see the point.

blocks|key|887712|text|耦合与系统之间的依赖有关，可以是代码模块(函数、文件或类)、管道中的工具、服务器-客户端进程等。依赖关系越不普遍，它们就变得越“紧密耦合”，因为更改一个系统需要更改依赖它的其他系统。理想的情况是“松散耦合”，其中一个系统可以改变，系统依赖于它将继续工作，而不需要修改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|887713|实现松散耦合的一般方法是通过定义良好的接口。如果两个系统之间的相互作用在双方都有明确的定义和遵守，那么就更容易修改一个系统，同时确保这些约定不会被打破。在实践中通常会发生这样的情况，即没有建立定义良好的接口，导致设计草率和耦合紧密。|887714|下面是一些例子：|887715|应用程序依赖于库。在紧密耦合的情况下，应用程序中断在较新版本的lib上。谷歌"DLL地狱“。|unordered-list-item|887716|客户端应用程序从服务器读取数据。在紧密耦合的情况下，对服务器的更改需要在客户端进行修复。|887717|两个类在一个面向对象的层次结构中交互。在紧密耦合的情况下，对一个类的更改要求更新另一个类以匹配。|887718|多个命令行工具在管道中通信。如果它们紧密耦合，对一个命令行工具版本的更改将导致读取其输出的工具出现错误。|887719|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|T|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|U|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|V|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|W|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|P|$]]

Coupling has to do with dependencies between systems, which could be modules of code (functions, files, or classes), tools in a pipeline, server-client processes, and so forth. The less general the dependencies are, the more "tightly coupled" they become, since changing one system required changing the other systems that rely on it. The ideal situation is "loose coupling" where one system can be changed and the systems depending on it will continue to work without modification.

The general way to achieve loose coupling is through well defined interfaces. If the interaction between two systems is well defined and adhered to on both sides, then it becomes easier to modify one system while ensuring that the conventions are not broken. It commonly occurs in practice that no well-defined interface is established, resulting in a sloppy design and tight coupling.

Some examples:

<ul>
<li>Application depends on a library. Under tight coupling, app breaks on newer versions of the lib. Google for "DLL Hell".</li>
<li>Client app reads data from a server. Under tight coupling, changes to the server require fixes on the client side.</li>
<li>Two classes interact in an Object-Oriented hierarchy. Under tight coupling, changes to one class require the other class to be updated to match.</li>
<li>Multiple command-line tools communicate in a pipe. If they are tightly coupled, changes to the version of one command-line tool will cause errors in the tools that read its output.</li>
</ul>

blocks|key|242426|text|这里的答案之间的差异程度说明了为什么要理解这个概念很难，但我可以简单地描述它：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|242427|为了让我知道，如果我扔一个球给你，那么你可以抓住它，我真的不需要知道你多大。我不需要知道你早餐吃了什么，我也不在乎你的第一次迷恋是谁。我只需要知道你能抓到。如果我知道这一点，那么我不在乎是你，我是在向你或你的兄弟扔球。|242428|使用c#或Java等非动态语言，我们通过接口来实现这一点.因此，假设我们有以下接口：|242429|public+ICatcher
{
+++public+void+Catch();
}|code-block|syntax|javascript|242430|现在，假设我们有以下类：|242431|public+CatcherA+:+ICatcher
{
+++public+void+Catch()
+++{
++++++console.writeline("You+Caught+it");
+++}

}
public+CatcherB+:+ICatcher
{
+++public+void+Catch()
+++{
++++++console.writeline("Your+brother+Caught+it");
+++}

}|242432|现在，CatcherA和CatcherB都实现了Catch方法，所以需要守望者的服务可以使用这两种方法中的任何一种，而不关心它是哪一种。因此，紧密耦合的服务可以直接实例化捕获的服务。|offset|length|style|CODE|242433|public+CatchService
{
+++private+CatcherA+catcher+=+new+CatcherA();

+++public+void+CatchService()
+++{
++++++catcher.Catch();
+++}

}|242434|因此，CatchService可以完全按照它的计划来做，但是它使用CatcherA，并且总是使用CatcherA。它的硬编码，所以它停留在那里，直到有人出现，并改造它。|242435|现在让我们选择另一个选项，称为依赖注入：|242436|public+CatchService
{
+++private+ICatcher+catcher;

+++public+void+CatchService(ICatcher+catcher)
+++{
++++++this.catcher+=+catcher;
++++++catcher.Catch();
+++}
}|242437|因此，实例化CatchService的调用可以执行以下操作：|242438|CatchService+catchService+=+new+CatchService(new+CatcherA());|242439|或|242440|CatchService+catchService+=+new+CatchService(new+CatcherB());|242441|这意味着Catch服务没有紧密耦合到CatcherA或CatcherB。|242442|还有几种用于松散耦合服务的其他策略，如使用IoC框架等。|242443|entityMap^0|0|0|0|0|0|0|3|8|C|8|O|5|0|0|3|C|X|8|1C|8|0|0|0|6|C|0|0|0|0|4|5|I|8|R|8|0|0^^$0|@$1|2|3|4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1I|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1J|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1K|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|1L|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|1M|8|@$Q|1N|R|1O|S|T]|$Q|1P|R|1Q|S|T]|$Q|1R|R|1S|S|T]]|9|@]|A|$]]|$1|U|3|V|5|H|7|1T|8|@]|9|@]|A|$I|J]]|$1|W|3|X|5|6|7|1U|8|@$Q|1V|R|1W|S|T]|$Q|1X|R|1Y|S|T]|$Q|1Z|R|20|S|T]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|21|8|@]|9|@]|A|$]]|$1|10|3|11|5|H|7|22|8|@]|9|@]|A|$I|J]]|$1|12|3|13|5|6|7|23|8|@$Q|24|R|25|S|T]]|9|@]|A|$]]|$1|14|3|15|5|H|7|26|8|@]|9|@]|A|$I|J]]|$1|16|3|17|5|6|7|27|8|@]|9|@]|A|$]]|$1|18|3|19|5|H|7|28|8|@]|9|@]|A|$I|J]]|$1|1A|3|1B|5|6|7|29|8|@$Q|2A|R|2B|S|T]|$Q|2C|R|2D|S|T]|$Q|2E|R|2F|S|T]]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2H|8|@]|9|@]|A|$]]]|1F|$]]

The degree of difference between answers here shows why it would be a difficult concept to grasp but to put it as simply as I can describe it:
In order for me to know that if I throw a ball to you, then you can catch it I really dont need to know how old you are. I dont need to know what you ate for breakfast, and I really dont care who your first crush was. All I need to know is that you can catch. If I know this, then I dont care if its you I am throwing a ball to you or your brother.
With non-dynamic languages like c# or Java etc, we accomplish this via Interfaces. So lets say we have the following interface:
<pre><code>public ICatcher
{
 public void Catch();
}
</code></pre>
And now lets say we have the following classes:
<pre><code>public CatcherA : ICatcher
{
 public void Catch()
 {
 console.writeline(&quot;You Caught it&quot;);
 }

}
public CatcherB : ICatcher
{
 public void Catch()
 {
 console.writeline(&quot;Your brother Caught it&quot;);
 }

}
</code></pre>
Now both <code>CatcherA</code> and <code>CatcherB</code> implement the <code>Catch</code> method, so the service that requires a Catcher can use either of these and not really give a damn which one it is. So a tightly coupled service might directly instantiate a catched i.e.
<pre><code>public CatchService
{
 private CatcherA catcher = new CatcherA();

 public void CatchService()
 {
 catcher.Catch();
 }

}
</code></pre>
So the <code>CatchService</code> may do exactly what it has set out to do, but it uses <code>CatcherA</code> and will always user <code>CatcherA</code>. Its hard coded in, so its staying there until someone comes along and refactors it.
Now lets take another option, called dependency injection:
<pre><code>public CatchService
{
 private ICatcher catcher;

 public void CatchService(ICatcher catcher)
 {
 this.catcher = catcher;
 catcher.Catch();
 }
}
</code></pre>
So the calls that instantiate <code>CatchService</code> may do the following:
<pre><code>CatchService catchService = new CatchService(new CatcherA());
</code></pre>
or
<pre><code>CatchService catchService = new CatchService(new CatcherB());
</code></pre>
This means that the <code>Catch</code> service is not tightly coupled to either <code>CatcherA</code> or <code>CatcherB</code>.
There are several other strategies for loosely coupling services like this such as the use of an IoC framework etc.

blocks|key|1241430|text|当两个组件依赖于彼此的具体实现时，它们是高度耦合的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1241431|假设我在类中的某个方法中有这样的代码：|1241432|this.some_object+=+new+SomeObject();|code-block|syntax|javascript|1241433|现在我的课依赖于SomeObject，它们是高度耦合的。另一方面，假设我有一个方法InjectSomeObject：|1241434|void+InjectSomeObject(ISomeObject+so)+{+//+note+we+require+an+interface,+not+concrete+implementation
++this.some_object+=+so;
}|1241435|然后，第一个示例可以只使用注入的SomeObject。--这在测试过程中很有用。在正常操作的中，您可以使用繁重的、使用数据库的、使用网络的类等等，而对于通过轻量级的模拟实现的测试，您可以使用这些类。与紧密耦合的代码，您不能这样做.|offset|length|style|BOLD|1241436|您可以通过使用依赖注入容器来简化此工作的某些部分。您可以在维基百科：注入上阅读有关DI的更多信息。|1241437|--有时候这太容易了。--你必须使事情具体化，否则你的程序的可读性和可理解性就会变差。因此，主要在组件边界上使用这种技术，并且知道您在做什么。确保您正在利用松耦合。如果不是，你可能不需要它在那个地方。DI可能会使你的程序更加复杂。确保你做了一个好的权衡。换句话说，保持良好的平衡。就像设计系统时一样。祝好运!|1241438|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Dependency_injection^0|0|0|0|0|0|R|J|2R|G|0|Y|2|0|0|0|B|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|17|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|19|8|@$O|1A|P|1B|Q|R]|$O|1C|P|1D|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1E|8|@]|9|@$O|1F|P|1G|1|1H]]|A|$]]|$1|U|3|V|5|6|7|1I|8|@$O|1J|P|1K|Q|R]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

Two components are higly coupled when they depend on concrete implementation of each other.

Suppose I have this code somewhere in a method in my class:

<pre><code>this.some_object = new SomeObject();
</code></pre>

Now my class depends on SomeObject, and they're highly coupled. On the other hand, let's say I have a method InjectSomeObject:

<pre><code>void InjectSomeObject(ISomeObject so) { // note we require an interface, not concrete implementation
 this.some_object = so;
}
</code></pre>

Then the first example can just use injected SomeObject. This is useful during testing. With normal operation you can use heavy, database-using, network-using classes etc. while for tests passing a lightweight, mock implementation. With tightly coupled code you can't do that.

You can make some parts of this work easer by using dependency injection containers. You can read more about DI at Wikipedia: <a href="http://en.wikipedia.org/wiki/Dependency_injection" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Dependency_injection</a>.

It is sometimes easy to take this too far. At some point you have to make things concrete, or your program will be less readable and understandable. So use this techniques mainly at components boundary, and know what you are doing. Make sure you are taking advantage of loose coupling. If not, you probably don't need it in that place. DI may make your program more complex. Make sure you make a good tradeoff. In other words, maintain good balance. As always when designing systems. Good luck!

blocks|key|242517|text|在计算机科学中，“松耦合”的另一个含义是没有人在这里发布过，所以.这里--希望你能给我一些选票，这样就不会在堆底输掉了！当然，我答案的主题应该是对这个问题的任何全面的回答.即：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|242518|术语“松散耦合”首先作为一个术语进入计算，用于描述多CPU配置中的CPU体系结构。它的对应术语是“紧密耦合”。松散耦合是CPU没有共享许多资源的时候，而紧耦合是当它们共享资源的时候。|242519|“系统”这个词在这里可能会很混乱，所以请仔细分析一下情况。|242520|通常，但并非总是，在一个系统中存在的硬件配置中的多个CPU(如在单个"PC“盒中)将紧密耦合。除了一些具有跨“系统”共享主内存的子系统的超高性能系统外，所有可除系统都是松散耦合的。|242521|紧耦合和松散耦合的术语是在多线程和多核CPU被发明之前引入的，因此这些术语可能需要一些伙伴来充分表达今天的情况。事实上，今天我们很可能有一个系统，它把两种类型都包含在一个整体系统中。对于当前的软件系统，有两种常见的体系结构，每种体系结构中的一种，它们非常常见--它们应该是家常便饭。|242522|首先，由于问题是关于什么的，一些松散耦合系统的例子如下：|242523|VaxClusters|unordered-list-item|242524|Linux集群|242525|相反，一些紧密耦合的例子：|242526|Semetrical-多处理(SMP)操作系统-例如Fedora+9|242527|多线程CPU|242528|多核CPU|242529|在今天的计算中，这两种操作在一个单一的整体系统中的例子并不少见。例如，以运行Fedora+9的Pentium双或四核CPU为例--这些是紧密耦合的计算系统。然后，将其中的几个合并到一个松散耦合的Linux集群中，您现在就可以进行松散和紧密耦合的计算了！哦，现代的硬件真是太棒了！|242530|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|18|8|@]|9|@]|A|$]]|$1|O|3|P|5|N|7|19|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1A|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|1B|8|@]|9|@]|A|$]]|$1|U|3|V|5|N|7|1C|8|@]|9|@]|A|$]]|$1|W|3|X|5|N|7|1D|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1E|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|11|$]]

In computer science there is another meaning for "loose coupling" that no one else has posted about here, so... Here goes - hopefully you'll give me some votes up so this isn't lost at the bottom of the heap! SURELY the subject of my answer belongs in any comprehensive answer to the question... To wit:

The term "Loose Coupling" first entered computing as a term used as an adjective regarding CPU architecture in a multi-CPU configuration. Its counterpart term is "tight coupling". Loose Coupling is when CPUs do not share many resources in common and Tight Coupling is when they do.

The term "system" can be confusing here so please parse the situation carefully.

Usually, but not always, multiple CPUs in a hardware configuration in which they exist within one system (as in individual "PC" boxes) would be tightly coupled. With the exception of some super-high-performance systems that have subsystems that actually share main memory across "systems", all divisible systems are loosely coupled.

The terms Tightly Coupled and Loosely Coupled were introduced before multi-threaded and multi-core CPUs were invented, so these terms may need some companions to fully articulate the situation today. And, indeed, today one may very well have a system that encompases both types in one overall system. Regarding current software systems, there are two common architectures, one of each variety, that are common enough these should be familliar.

First, since it was what the question was about, some examples of Loosely Coupled systems:

<ul>
<li>VaxClusters</li>
<li>Linux Clusters</li>
</ul>

In contrast, some Tightly Coupled examples:

<ul>
<li>Semetrical-Multi-Processing (SMP) Operating systems - e.g. Fedora 9</li>
<li>Multi-threaded CPUs</li>
<li>Multi-Core CPUs</li>
</ul>

In today's computing, examples of both operating in a single overall system is not uncommon. For example, take modern Pentium dual or quad core CPUs running Fedora 9 - these are tightly-coupled computing systems. Then, combine several of them in a loosely coupled Linux Cluster and you now have both loosely and tightly coupled computing going on! Oh, isn't modern hardware wonderful!

blocks|key|242555|text|这里有一些很长的答案。但原则很简单。我提交了维基百科的开场白|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|242556|“松散耦合描述了具有某种交换关系的两个或多个系统或组织之间的弹性关系。|242557|事务的每一端都明确其需求，并且对另一端几乎不作假设。“|242558|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Loose_coupling^0|M|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

Some long answers here. The principle is very simple though. I submit the opening statement from <a href="http://en.wikipedia.org/wiki/Loose_coupling" rel="nofollow noreferrer">wikipedia</a>:

"Loose coupling describes a resilient relationship between two or more systems or organizations with some kind of exchange relationship. 

Each end of the transaction makes its requirements explicit and makes few assumptions about the other end."

blocks|key|883559|text|许多集成产品(尤其是苹果公司的产品)，比如iPods、iPads就是紧密耦合的一个很好的例子:一旦电池死了，你最好买一台新设备，因为电池是焊接固定的，不会松动，因此更换起来非常昂贵。一个松散耦合的玩家可以毫不费力地更换电池。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|883560|软件开发也是如此:通常(更好)使用松散耦合的代码来促进扩展和替换(并使单个部件更易于理解)。但是，很少有，在特殊情况下，紧密耦合可能是有利的，因为紧密集成的几个模块允许更好的优化。|883561|entityMap^0|L|5|R|5|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Many integrated products (especially by Apple) such as iPods, iPads are a good example of tight coupling: once the battery dies you might as well buy a new device because the battery is soldered fixed and won't come loose, thus making replacing very expensive. A loosely coupled player would allow effortlessly changing the battery.

The same goes for software development: it is generally (much) better to have loosely coupled code to facilitate extension and replacement (and to make individual parts easier to understand). But, very rarely, under special circumstances tight coupling can be advantageous because the tight integration of several modules allows for better optimisation.

blocks|key|887840|text|我提出了一种非常简单的码耦合测试方法。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|887841|如果对代码段B存在任何可能的修改，则代码的段A与代码的段B紧密耦合，这将迫使代码段A中的更改以保持正确性。|ordered-list-item|887842|如果没有可能对代码段B进行必要的修改，则代码段A与代码段B不紧密耦合。|887843|这将帮助您验证代码片段之间有多少耦合。有关这方面的推理，请参阅以下博客文章：http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/|887844|entityMap|0|LINK|mutability|MUTABLE|url|http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/^0|B|3|0|0|0|12|2X|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|X|8|@]|D|@]|E|$]]|$1|I|3|J|5|H|7|Y|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|Z|8|@]|D|@$9|10|A|11|1|12]]|E|$]]|$1|M|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|N|$O|$5|P|Q|R|E|$S|T]]]]

I propose a very simple Test of Code Coupling:

<ol>
<li>Piece A of code is tightly coupled to Piece B of code if there exists any possible modification to the Piece B that would force changes in Piece A in order to keep correctness.</li>
<li>Piece A of code is not tightly coupled to Piece B of code if there is no possible modification to the Piece B that would make a change to Piece A necessary.</li>
</ol>

This will help you to verify how much coupling there is between the pieces of your code.
for reasoning on that see this blog post: <a href="http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/" rel="nofollow">http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/</a>

blocks|key|887866|text|在简单的语言中，松散耦合意味着它不依赖于其他事件的发生。它独立执行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|887867|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In simple language, loosely coupled means it doesn’t depend on other event to occur. It executes independently.

blocks|key|1241765|text|当在其他类中使用new关键字创建类的对象时，实际上是在执行紧密耦合(糟糕的实践)，而应该使用松散耦合，这是一个很好的实践。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1241766|-A.java|1241767|package+interface_package.loose_coupling;

public+class+A+{

void+display(InterfaceClass+obji)
{
++++obji.display();
++++System.out.println(obji.getVar());
}
}|code-block|syntax|javascript|1241768|-B.java|1241769|package+interface_package.loose_coupling;

public+class+B+implements+InterfaceClass{

private+String+var="variable+Interface";

public+String+getVar()+{
++++return+var;
}

public+void+setVar(String+var)+{
++++this.var+=+var;
}

@Override
public+void+display()+{
++++//+TODO+Auto-generated+method+stub
++++System.out.println("Display+Method+Called");
}
}|1241770|-接口类|1241771|package+interface_package.loose_coupling;

public+interface+InterfaceClass+{

void+display();
String+getVar();
}|1241772|-大班|1241773|package+interface_package.loose_coupling;

public+class+MainClass+{

public+static+void+main(String[]+args)+{
++++//+TODO+Auto-generated+method+stub

++++A+obja=new+A();
++++B+objb=new+B();
++++obja.display(objb);+++++//Calling+display+of+A+class+with+object+of+B+class+
++++
}
}|1241774|解释：|1241775|在上面的例子中，我们有两个A类和B类|1241776|B类实现了接口，即InterfaceClass。|1241777|InterfaceClass为B类定义了一个契约，因为InterfaceClass具有B类的抽象方法，可以被任何其他类访问，例如A。|1241778|在A类中，我们有一个显示方法，除了实现InterfaceClass的类的对象(在我们的例子中是B类)之外。在这个对象上，A类的方法是调用B类的display()和getVar()|1241779|在MainClass中，我们创建了A类和B类的对象，并通过传递B类的对象(+objb+)来调用A的显示方法。用B类的对象调用A的显示方法。|1241780|现在谈论松耦合。假设将来您必须将B类的名称更改为ABC，那么您就不必在B类的显示方法中更改它的名称，只需创建new+(ABC类)的对象，然后在MailClass中将其传递给显示方法。你不需要改变A类的任何东西|1241781|参考文献：https://speckyfox.com/blog/5-steps-to-loose-coupling-in-java-using-interfaces|1241782|entityMap|0|LINK|mutability|MUTABLE|url|https://speckyfox.com/blog/5-steps-to-loose-coupling-in-java-using-interfaces^0|8|3|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|5|25|0|0^^$0|@$1|2|3|4|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1P|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|1Q|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1R|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|1S|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|1T|8|@]|D|@]|E|$]]|$1|S|3|T|5|J|7|1U|8|@]|D|@]|E|$K|L]]|$1|U|3|V|5|6|7|1V|8|@]|D|@]|E|$]]|$1|W|3|X|5|J|7|1W|8|@]|D|@]|E|$K|L]]|$1|Y|3|Z|5|6|7|1X|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|1Y|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|14|3|15|5|6|7|20|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|21|8|@]|D|@]|E|$]]|$1|18|3|19|5|6|7|22|8|@]|D|@]|E|$]]|$1|1A|3|1B|5|6|7|23|8|@]|D|@]|E|$]]|$1|1C|3|1D|5|6|7|24|8|@]|D|@$9|25|A|26|1|27]]|E|$]]|$1|1E|3|-4|5|6|7|28|8|@]|D|@]|E|$]]]|1F|$1G|$5|1H|1I|1J|E|$1K|1L]]]]

When you create an object of a class using the <code>new</code> keyword in some other class, you are actually doing tight coupling (bad practice) instead you should use loose coupling which is a good practice
---A.java---
<pre><code>package interface_package.loose_coupling;

public class A {

void display(InterfaceClass obji)
{
 obji.display();
 System.out.println(obji.getVar());
}
}
</code></pre>
---B.java---
<pre><code>package interface_package.loose_coupling;

public class B implements InterfaceClass{

private String var=&quot;variable Interface&quot;;

public String getVar() {
 return var;
}

public void setVar(String var) {
 this.var = var;
}

@Override
public void display() {
 // TODO Auto-generated method stub
 System.out.println(&quot;Display Method Called&quot;);
}
}
</code></pre>
---InterfaceClass---
<pre><code>package interface_package.loose_coupling;

public interface InterfaceClass {

void display();
String getVar();
}
</code></pre>
---MainClass---
<pre><code>package interface_package.loose_coupling;

public class MainClass {

public static void main(String[] args) {
 // TODO Auto-generated method stub

 A obja=new A();
 B objb=new B();
 obja.display(objb); //Calling display of A class with object of B class 
 
}
}
</code></pre>
Explanation:
In the above example, we have two classes A and B
Class B implements Interface i.e. InterfaceClass.
InterfaceClass defines a Contract for B class as InterfaceClass has abstract methods of B class that can be accessed by any other class for example A.
In Class A we have a display method which can except object of class that implements InterfaceClass (in our case it is B class). And on that object method of class A is calling display() and getVar() of class B
In MainClass we have created object of Class A and B. And calling display method of A by passing object of B class i.e. objb. Display method of A will be called with object of B class.
Now talking about loose coupling. Suppose in the future you have to change the name of Class B to ABC then you do not have to change its name in the display method of class B, just make the object of new (ABC class) and pass it to the display method in MailClass. You do not have to change anything in Class A
ref: <a href="https://speckyfox.com/blog/5-steps-to-loose-coupling-in-java-using-interfaces" rel="nofollow noreferrer">https://speckyfox.com/blog/5-steps-to-loose-coupling-in-java-using-interfaces</a>

blocks|key|1241798|text|耦合是指不同的类之间连接得有多紧密。紧密耦合的类包含大量的交互和依赖关系。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1241799|松散耦合的类正好相反，它们之间的依赖关系保持在最小程度，而是依赖于彼此定义良好的公共接口。|1241800|乐高玩具，SNAP在一起的玩具将被视为松散耦合，因为你只需将碎片拼凑在一起，并建立任何你想要的系统。然而，拼图中有紧密耦合的部分。你不能从一个拼图拼图(系统)中拿出一块拼图，然后把它分解成不同的拼图，因为系统(拼图)非常依赖于特定于特定“设计”的特定部分。乐高是建立在一个更通用的方式，以便他们可以使用在您的乐高屋，或在我的乐高外星人。|1241801|参考资料：https://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/|offset|length|1241802|entityMap|0|LINK|mutability|MUTABLE|url|https://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/^0|0|0|0|5|1T|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$H|V|I|W|1|X]]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Coupling refers to how tightly different classes are connected to one another. Tightly coupled classes contain a high number of interactions and dependencies. 

Loosely coupled classes are the opposite in that their dependencies on one another are kept to a minimum and instead rely on the well-defined public interfaces of each other.

Legos, the toys that SNAP together would be considered loosely coupled because you can just snap the pieces together and build whatever system you want to. However, a jigsaw puzzle has pieces that are TIGHTLY coupled. You can’t take a piece from one jigsaw puzzle (system) and snap it into a different puzzle, because the system (puzzle) is very dependent on the very specific pieces that were built specific to that particular “design”. The legos are built in a more generic fashion so that they can be used in your Lego House, or in my Lego Alien Man. 

Reference: <a href="https://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/" rel="noreferrer">https://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/</a>

I can't seem to grok the concept of "loose coupling." I suppose it doesn't help that the word "loose" usually has a negative connotation, so I always forget that loose coupling is a good thing.

Will somebody please show some "before" and "after" code (or pseudocode) that illustrates this concept?

What is "loose coupling?" Please provide examples

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我似乎无法理解“松耦合”的概念。我想“松散”这个词通常有一个负面的含义，这一点也没有帮助，所以我总是忘记松耦合是一件好事。请有人展示一些“前”和“后”代码(或伪代码)来说明这个概念吗？

问什么是“松耦合”？请举例说明
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是“松耦合”？请举例说明EN