正确的即使您编写了一个接口或协议，您也在致力于某些事情。你可以平静地忘记100%的解耦，并放心，无论你做什么，你都不能在不做任何小修改的情况下，只弹出一个组件并将另一个组件放在它的位置上，除非你致力于非常基本的协议，如HTTP（甚至在那时）

毕竟，我们人类只是宽松的标准。这就是为什么我们有。。。好吧，没关系。

如果组件是100%解耦的，这意味着它们不会相互通信。

实际上有不同类型的耦合。但一般的想法是，如果对象不相互依赖，那么它们就不会耦合。

你可以做到这一点。想象一下通过网络相互通信的两个组件。一个组件可以在Windows上运行，而另一个组件则可以在Unix上运行。这不是100%脱钩吗？

至少，防火墙保护，至少从某个接口开始，需要允许每台机器的流量流向另一台机器。仅此一点就可以被视为一种耦合形式，因此，耦合是通信机器固有的，至少在一定程度上是这样。

这可以通过引入两个组件都能理解的通信接口或协议而不是在组件之间直接传递数据来实现。

Well two webservices that don t reference each other might be a good example of 100% decoupled. The coupling would then arrive in the form of an app util that "couples" them together by using them both.

耦合本质上并不坏，但您必须做出可靠的判断，决定何时进行（是仅在实现中进行，还是在您的框架本身中进行？）以及耦合是否合理。

如果组件被设计为100%正交，那么这应该是可能的。明确的关注点分离可以实现这一点。组件所需要知道的只是其输入的接口。

耦合应该是单向的：组件知道其参数的语义，但应该是彼此不可知的。

一旦组件之间有1%的耦合，1%就开始增长（在持续时间稍长的系统中）

然而，通常在对等组件中注入知识以实现更高的性能。

即使两个组件不直接通信，使用其他两个组件的第三个组件也是系统的一部分，并且与它们耦合。

@Vadmyst：如果您的组件通过网络进行通信，它们必须使用某种协议，该协议与两个本地组件的接口相同。

这是一个令人痛苦的抽象问题。如果所述系统是单个应用程序的组件，则存在各种技术，例如涉及MVC（模型-视图-控制器）和用于IoC/依赖注入的接口的技术，这些技术有助于组件的解耦。

从物理隔离的软件体系结构的角度来看，CORBA和COM支持本地或网络互操作，并使用ATL之类的“通用语言”。这些已经被诸如SOAP之类的XML服务所弃用，SOAP使用WSDL来执行耦合。没有什么能阻止SOAP客户端使用WSDL进行运行时延迟耦合，尽管我很少看到它。还有一些东西，比如JSON，它和XML一样，但经过了优化，还有谷歌协议缓冲区，它优化了互操作，但通常是预编译的，而不是延迟耦合。

当涉及到IPC（进程间通信）时，两个系统只需要说一个通用的“协议”。这可以是XML，也可以是共享类库，或者是专有的东西。即使在专有级别，您仍然通过内存流、TCP/IP网络、共享文件（内存或硬盘）或其他机制“耦合”，并且仍然使用字节，最终使用1秒和0s。

因此，最终这个问题真的无法得到公平的回答；严格地说，只有相互之间没有任何关系的系统才能达到100%。根据上下文完善你的问题。

区分直接成分和间接成分很重要。尽量删除直接连接（一个类引用另一个类），转而使用间接连接。将两个无知的类与管理它们交互的第三个类绑定。

这将类似于表单上的一组用户控件，或者数据库连接池和连接池类。更基本的组件（控件和连接）由更高层（表单和连接池）管理，但没有基本组件知道其他组件。基本组件公开了事件和方法，而另一部分则牵线搭桥。

不，我们不能。阅读Joel的精彩文章泄漏抽象定律，它让许多人大开眼界。然而，这不一定是一件糟糕的事情，事实确实如此。泄漏抽象提供了很好的机会，因为它们使底层平台可被利用。

在很长一段时间内认真思考API，然后确保它尽可能小，直到它几乎消失。。。

Lego软件流程提出了这个……：）-实际上很好地实现了这个。。。

一个生物体的两个细胞有多“紧密耦合”。。。？

生物体内的细胞仍然可以进行通信，但它们不是通过任何需要了解接收（或发送）部分的方式进行通信，而是通过向体内释放化学物质来进行通信…；）