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