1

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

  1. 将所有这些功能作为单独的功能提供。

  2. 仅公开一个以 XML 作为输入的函数。根据指定的 request_Type 和 XML 中传递的参数，我在内部调用了相应的函数之一。

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

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

Q2。就 OOP 而言，其中哪一个是更好的设计，为什么？

编辑：

如果我通过 D-Bus 公开这个 API 供其他人使用，类型检查是否仍然是比较这两种方法的考虑因素？据我了解，类型检查是在编译时完成的，但是如果这个函数通过一些 IPC 暴露出来，类型检查的问题就会出现？

4

1 回答 1

3

您建议的两个替代方案在您希望从 API 提供的“功能”数量（显然相当大）方面没有区别。然而，第二个似乎有很多缺点，因为你失去了任何强类型检查，记录功能等变得更加困难。（我看到的唯一优点是，如果你添加功能，你不需要更改你的 API . 但缺点是用户直到运行时才能弄清楚 API 更改（如删除的函数）。）

与这个问题更相关的是单一责任原则（http://en.wikipedia.org/wiki/Single_responsibility_principle）。当你在谈论 OOP 时，你不应该在一个类中公开你的数十个函数，而是将它们拆分到不同的类中，每个类都有一个单一的职责。定义良好的“职责”和角色需要一些练习，但遵循一些基本准则将帮助您快速入门。请参阅OOP 是否有任何规则？一个好的起点。

回复问题编辑

我没有使用过 D-Bus，所以这可能是完全错误的。但是通过快速浏览我阅读的教程

每个对象都支持一个或多个接口。将接口视为一组命名的方法和信号，就像在 GLib、Qt 或 Java 中一样。接口定义对象实例的类型。

DBus 使用简单的命名空间字符串标识接口，例如 org.freedesktop.Introspectable。大多数绑定会将这些接口名称直接映射到适当的编程语言结构，例如 Java 接口或 C++ 纯虚拟类。

据我了解，D-Bus 具有不同对象的概念，这些对象提供由多种方法组成的接口。这意味着（对我而言）我上面的回答仍然适用。指定 API 的“D-Bus 本机”方式意味着展示接口，我看不出好的 OOP 设计指南不应该有效的任何理由，在这里。由于 D-Bus 似乎将这些甚至映射到本地语言结构，这更有可能。

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

于 2013-03-04T12:58:02.067 回答