我有一个组件，它的 API 公开了大约 10 种功能。我可以想到两种方法来实现它：
将所有这些功能作为单独的函数提供。
仅公开一个以 XML 作为输入的函数。根据指定的 request_Type 和 XML 中传递的参数，我在内部调用了相应的函数之一。
第一季度。第二种设计会比第一种更松散耦合吗？
我总是读到我应该如何尝试我的组件松散耦合，我真的应该到这种程度来实现失去耦合吗？
第二季度。就 OOP 而言，其中哪一个是更好的设计？为什么？
编辑：
如果我通过 D-Bus 公开这个 API 以供其他人使用，类型检查是否仍然是比较这两种方法的考虑因素？据我了解，类型检查是在编译时完成的，但是如果这个函数通过一些 IPC 暴露出来，类型检查的问题就会出现？
【问题讨论】：
标签： api oop loose-coupling
您提出的两个备选方案在您希望通过 API 提供的“功能”数量（显然相当多）方面没有区别。然而，第二个似乎有很多缺点，因为你失去了任何强类型检查，记录功能等变得更加困难。（我看到的唯一优点是，如果你添加功能，你不需要更改你的 API . 但缺点是用户直到运行时才能弄清楚 API 更改（如删除的函数）。）
与这个问题更相关的是单一责任原则 (http://en.wikipedia.org/wiki/Single_responsibility_principle)。当你在谈论 OOP 时，你不应该在一个类中公开你的数十个函数，而是将它们拆分到不同的类中，每个类都有一个单一的职责。定义好的“职责”和角色需要一些练习，但遵循一些基本准则将帮助您快速入门。请参阅Are there any rules for OOP? 以获得良好的起点。
回复问题编辑
我没有使用过 D-Bus，所以这可能是完全错误的。但从我读到的tutorial 快速浏览
每个对象都支持一个或多个接口。将接口视为 一组命名的方法和信号，就像在 GLib 或 Qt 中一样 爪哇。接口定义对象实例的类型。
DBus 用一个简单的命名空间字符串来识别接口，比如 像 org.freedesktop.Introspectable。大多数绑定将映射这些 接口名称直接指向适当的编程语言 构造，例如 Java 接口或 C++ 纯虚拟类。
据我了解，D-Bus 具有不同对象的概念，这些对象提供由多种方法组成的接口。这意味着（对我而言）我上面的回答仍然适用。指定 API 的“D-Bus 本机”方式意味着展示接口，我看不出好的 OOP 设计指南不应该有效的任何理由，这里。由于 D-Bus 似乎将这些甚至映射到本地语言结构，这更有可能。
当然，没有人会阻止您仅使用 XML 构建自己的 API 描述语言。但是，诸如此类的事情是对底层技术的某种滥用。你应该有充分的理由做这样的事情。
【讨论】：