写出好维护的程式码 — 低耦合

在这个单元我们要来谈耦合，以及如何透过这个原则，让我们在写程式的时候，能够让程式码更容易修改跟拓展。

相信多数人可能过去都听过高内聚、低耦合这两个概念放在一起谈。我们在上一个单元谈了高内聚，在这个单元我们会进一步谈低耦合，让大家知道这两个概念放在一起，可以如何一起让我们的程式码变得更容易维护。

复杂度与可维护性

在这边我们再复习一下前面的单元。要让程式码能够好维护，就是让程式码的复杂度要低，推荐有两个检视指标：

• 第一个是程式码是不是好读的，也就是过去假设没有碰过这段程式码的人，他第一次看到这段程式码，能不能用非常短的时间就去理解这段程式码。
• 第二个指标是好改，也就是如果某一个未来想要去维护这段程式码的人，想要去做改动，会不会想改的时候发现很难改，还是可以相对来讲很简单地去做他想要做的改动。

从耦合的角度来看，在好读的部分可能帮助并没有到那么大，但是假设从好改的角度来看，让程式码的耦合性降低，是能够让程式码的好改程度变高非常多。所以从复杂度的角度来看，低耦合这件事情也是非常有帮助的。

什么是耦合?

首先我们先来理解一下耦合这个词代表什么样的概念。所谓的耦合就是指事情相互牵扯的程度，也就是两个东西，它们彼此有没有互相的依赖、彼此纠缠在一起。假设有的话就是耦合度高，但假设彼此没有这种相互的牵扯、纠缠、依赖的话，那就是耦合度低。

事实上我们在日常的生活当中，也会看到不同的耦合的状况，不只是在程式当中而已。

举一个生活常见的案例，在过去苹果推出新手机的时候，使用的充电线都是苹果自家的 Lightning 充电线。用 Lightning 充电线的问题就会是，假设今天某一个用 iPhone Lightning 充电接头手机的人，出门手机要没电了，发现自己忘了带充电线，去跟身旁的人借，结果身旁的人都是使用 Android 的手机，都是使用标准的 Type-C 对 Type-C 的接头。

在这个状况下，因为苹果的手机跟 Lightning 的充电线是彼此耦合的，所以就变成它要充电的话，没有办法使用 Type-C 充电线。所以在这个时候，假设忘了带充电线，但身旁的人又都是用 Type-C 的充电线，就会导致想要借，借到了也没有办法充。

但反之，假设某一个人是用 Android 的手机，他出去忘了带充电线，旁边的人也都是使用这种标准化 Type-C 对 Type-C 接头的充电线，那这样子他忘了带充电线也没有关系。因为他的充电的接头，并没有跟某一个特定的充电接口是耦合的，所以他就可以非常轻松地使用别人的充电线，即使这个充电线是其他的厂牌也完全没有问题。

透过 MCP 协定解耦合

在了解了透过充电接头作为案例来谈耦合之后，我们回到技术的角度来看，在技术的设计或者程式设计上面，耦合这件事情会有什么样的影响。

这边提一个最近在谈 AI 一定会谈到的重要概念 MCP。MCP 当时的推出，其实也是在做解耦合这件事情。

我们先看到过去在还没有 MCP 这个统一的协定出现的时候，当 AI 的模型要去对接不同的外部工具，举例来讲，假设今天想要让 GPT 的模型去对接到 GitHub 相关的工具，让 GPT 的模型能够帮忙我们去发 PR，或者是去根据 PR 的留言去帮忙修改程式码。这些需要让 AI 代理去跟 GitHub 做互动的外部工具，在过去的做法是用所谓的函式呼叫(Function Calling) 的方式。

这个函式呼叫的做法，每一个 AI 的模型厂商提出来的，都是专属特定的函式呼叫。换句话说，函式呼叫的这个工具跟 AI 的模型彼此是耦合的。所以可以看到每一个模型，例如说 GPT 或者是 Gemini，它们对应的就是自家的厂商开发的这种函式呼叫的方式。所以假设今天某一个函式呼叫对应到 GPT 的模型，想要把它用到 Gemini 的模型就会没有办法用，因为它是跟 GPT 的模型耦合的。

所以从这个角度来看，开发的成本就会变很高。因为假设今天多一个模型，就需要多一个为这个模型去写的函式呼叫的方法。所以从可维护性的角度讲并不理想。

当时 MCP 被推出，就是想要去解决这个问题。MCP 是一个协定，而透过这个协定，当今天开发了某一个工具，不管是哪一个 AI 模型，只要它有支援 MCP 这个协定，就像我们前面谈的这个手机的案例，假设今天的这个手机不管是哪一个厂牌，假设它是支援 Type-C 的充电接口，那这样子充电线都是可以互相通用的。

而在 MCP 的角度也是，假设 AI 的模型有支援 MCP 这个协定、这个接口，这样子不管是哪一个模型，都可以去对接到相对应的工具。所以假设今天开发了一个 GitHub 的 MCP，它可以被用在不同的模型，或者是可以用在不同的工具，例如说用在 Cursor 或者用在 Copilot 这些不同的 AI 代理工具。

而这样子就可以做到，只要开发一个 GitHub 的 MCP，就能够用在所有不同的地方，而不用像左边的这张图，开发 GitHub 的函式呼叫(Function Calling)必须要针对每一个不同的模型，需要重复地写很多相似，但是只为了不同模型去做稍微调整的程式码。

所以可以看到，假设今天把工具跟模型之间的耦合拔掉，让彼此之间的耦合变低，可维护性就会提高。

阅读更多

如果读者们想更了解耦合这个主题，并有具体的程式码案例分析，以及低耦合在软体工程其他面向的应用，我们在 E+ 成长计划的主题文中，都有更详细谈。感兴趣的读者，可以在以下连结看到 E+ 的详细介绍 (连结)。

本文为 E+ 成长计划的深度内容，截取段落开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)。