决定耦合程度

Question

我有一个组件，它公开了大约10个功能的API。我可以想出两种方法来实现这个目标：

1. 将所有这些功能作为单独的功能进行分配。
2. 只公开一个以XML作为输入的函数。基于指定的request_Type和在XML中传递的参数，我在内部调用相应的函数之一。

Q1。第二种设计会比第一种更加松散吗？

我总是读到我应该如何尝试我的组件是松散耦合的，我真的应该达到这个程度来实现失去耦合吗？

Q2。从面向对象的角度来看，哪一种设计更好，为什么呢？

编辑：

如果我在D总线上公开这个API供其他人使用，那么类型检查是否仍然是比较这两种方法的考虑因素？据我所知，类型检查是在编译时完成的，但是如果这个函数在某些IPC上公开，类型检查的问题就会出现吗？

Answer 1

您建议的两个替代方案在您希望从API提供的“函数”数量(显然相当大)上并没有不同。但是，第二种方法似乎有许多缺点，因为您正在放松任何强类型检查，因此记录功能等就变得更加困难。(我看到的唯一优点是，如果添加功能，则不需要更改API。但缺点是，用户要到运行时才能找到类似已删除函数的API更改。)

与此相关的还有单责任原则 (原则)。当您谈论OOP时，您不应该在一个类中公开您的几十个函数，而应该将它们划分到不同的类中，每个类都有一个单独的责任。定义良好的“责任”和角色需要一些实践，但遵循一些基本准则将有助于您快速入门。有关良好的起点，请参见对OOP有什么规定吗？。

对问题的答复编辑

我没有用D-总线，所以这可能是完全错误的。但是从我读到的教程上看一下

每个对象都支持一个或多个接口。将接口看作是一组命名的方法和信号，就像在GLib、Qt或Java中一样。接口定义对象实例的类型。 DBus用一个简单的名称空间字符串标识接口，类似于org.freedesktop.Introspectable。大多数绑定都会将这些接口名称直接映射到适当的编程语言结构中，例如到Java接口或C++纯虚拟类。

据我所知，D总线有不同对象的概念，它提供由几种方法组成的接口。这对我来说意味着我上面的回答仍然适用。在这里，指定API的“D总线本机”方式意味着展示接口，我不认为好的OOP设计准则不应该有效的任何理由。由于D总线似乎甚至将这些映射到本地语言结构，这更有可能发生。

当然，没有人会阻止您使用XML构建自己的API描述语言。然而，像这样的事情是对底层技术的某种滥用。你应该有充分的理由去做这样的事情。