我们能否在一个系统的组件之间或者相互通信的不同系统之间实现100％的解耦？我认为这不可能。如果两个系统相互通信，则它们之间应该有某种程度的耦合。我对吗？

解决方案

回答

我们可以实现。想一下通过网络相互通信的两个组件。一个组件可以在Windows上运行，而其他组件可以在Unix上运行。那不是100％的解耦吗？

回答

如果组件是100％分离的，则意味着它们不会相互通信。

实际上，有不同类型的耦合。但是一般的想法是，如果对象彼此不依赖，则它们不会耦合。

回答

至少，防火墙保护(至少要从某个接口进行保护)需要允许来自每台计算机的通信流向另一台计算机。仅此一项就可以视为"耦合"的一种形式，因此，耦合对于至少在一定程度上进行通信的机器是固有的。

回答

这可以通过引入一个通讯接口或者协议来实现，这两个组件都可以理解并且不能在组件之间直接传递数据。

回答

两个彼此不引用的Web服务可能是100％分离的一个很好的例子。

然后，耦合将以app util的形式出现，通过同时使用两者将它们"耦合"在一起。

回答

耦合并不是天生的坏事，但是我们必须对何时进行耦合做出可靠的判断(是否仅在实现中，还是在框架本身中)，以及耦合是否合理。

正确的。即使我们写接口或者协议，也要承诺。我们可以和平地忘记100％的去耦，并且放心，无论我们做什么，都不能在没有至少任何微小修改的情况下直接摘取一个组件并在其位置上拍打另一个组件，除非我们承诺使用非常基本的协议，例如HTTP(甚至然后。)

回答

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

如果组件设计为100％正交，则应该可行。明确分离关注点可以实现此目的。组件只需知道其输入的接口即可。

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

一旦组件之间的耦合度为1％，则1％会开始增长(在持续时间更长的系统中)

回答

但是，经常将知识注入到对等组件中以实现更高的性能。

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

回答

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

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

从物理隔离的软件体系结构的角度来看，CORBA和COM支持本地或者网络互操作，并使用诸如ATL之类的"通用语言"。这些已被XML服务(例如SOAP)所弃用，该服务使用WSDL执行耦合。没有什么能阻止SOAP客户端使用WSDL进行运行时后期耦合，尽管我很少看到它。然后是诸如JSON(类似于XML但已优化)之类的东西，以及诸如Google协议缓冲区(Google Protocol Buffers)，其可优化互操作性，但通常是预编译的而不是后期耦合的。

当涉及IPC(进程间通信)时，两个系统只需要说出一个通用的"协议"。这可以是XML，可以是共享的类库，也可以是专有的东西。即使在专有级别，我们仍然会被内存流，TCP / IP网络，共享文件(内存或者硬盘)或者其他某种机制"耦合"，并且仍在使用字节，最终使用的是1和0。

回答

因此，最终，这个问题确实无法公平回答。严格来说，只有相互之间具有相互依存关系的系统才能达到100％。将问题优化为上下文。

区分直接和间接组件很重要。力求删除直接连接(一个类引用另一个类)，而改用间接连接。将两个"无知"类与管理它们之间的交互的第三个类绑定在一起。

回答

这就像是一组坐在窗体上的用户控件，或者是数据库连接池和连接池类。较基本的组件(控件和连接)由较高的组件(窗体和连接池)管理，但是没有一个基本组件知道其他组件。基本组件公开事件和方法，另一部分"拉字符串"。

回答

不，我们不能。阅读Joel的出色文章《泄漏抽象法则》，它使许多人大开眼界。但是，这并不一定是一件坏事，而是事实。泄漏的抽象提供了巨大的机会，因为它们使基础平台变得可利用。

在很长一段时间内都要非常仔细地考虑一下API，然后确保它尽可能的小，直到它几乎消失的地方为止。

乐高软件过程提出了这个... :)实际上可以很好地实现这一目标...

一个有机体的两个细胞是如何"紧密耦合"的？

段落数量不匹配