分割大接口

Question

我使用一个大的接口和大约50种方法来访问一个数据库。这个接口是我的一个同事写的。我们讨论了这一点：

我: 50种方法太多了。这是暗号的味道。

同事:我该怎么办？你想要数据库访问-你有。

我:是啊，但将来还不清楚，也很难维护。

同事:好吧，你说得对，这不太好。那么界面应该是什么样的呢？

Me: 5个返回对象的方法怎么样，每个对象都有10个方法？

嗯，但这不是一样吗？这真的会导致更清晰吗？值得付出努力吗？

我时不时会遇到这样一种情况，我想要一个接口，首先想到的是一个大接口。有一个通用的设计模式吗？

最新情况(对SJuan的评论作出答复)：

“类方法”：它是从数据库中获取数据的接口。所有方法都有形式(伪码)。

List<Typename> createTablenameList()

方法和表并不完全是1-1关系，更强调的是，您总是从数据库中得到某种类型的列表。

Answer 1

是的，50种方法是一种代码嗅觉，但是代码嗅觉意味着重新审视它，而不是它自动出错。如果每个使用该类的客户端都可能需要所有50个方法，则可能没有理由将其拆分。然而，这是不可能的。我的观点是，任意分割一个接口可能比根本不分割它更糟糕。

没有单一的模式来修复它，但是描述所需状态的原则是界面偏析原理 (实心中的'I‘)，它规定任何客户机都不应该被迫依赖它不使用的方法。

ISP的描述确实给了您一个如何修复它的提示:看看客户端。通常，仅仅通过查看一个类，似乎所有东西都应该放在一起，但是当您查看使用该类的客户端时，就会出现明显的划分。在设计接口时，一定要首先考虑客户端。

另一种确定接口是否应该被拆分的方法是通过进行第二个实现。最后经常发生的情况是，您的第二个实现不需要太多的方法，因此这些方法显然应该被拆分到它们自己的接口中。

Answer 2

同事:好吧，你说得对，这不太好。那么界面应该是什么样的呢？Me: 5个返回对象的方法怎么样，每个对象都有10个方法？

这不是一个很好的标准(实际上在这个声明中根本没有标准)。您可以根据它们进行分组(假设您的应用程序是金融事务应用程序，我的示例是这样的)：

• 功能(插入、更新、选择、事务、元数据、架构等)
• 实体(用户DAO，存款DAO等)
• 应用领域(财务交易、用户管理、总计等)
• 抽象级别(所有表访问代码都是一个单独的模块；所有选择的API都在各自的层次结构中，事务支持是独立的，模块中的所有转换代码，模块中的所有验证代码等等)

嗯，但这不是一样吗？这真的会导致更清晰吗？值得付出努力吗？

如果你选择了正确的标准，当然。如果你不这样做，肯定不会:)。

有几个例子：

• 看看ADODB对象中一个简单的OO原语示例(您的DB可能已经提供了此功能)。
• 查看Django数据模型(Django data model，https://docs.djangoproject.com/en/dev/topics/db/models/)，可以获得一个具有较高抽象级别的数据模型概念(在C++中，您可能需要更多的普通板代码，但这是一个不错的主意)。这个实现是在MVC设计模式中考虑到一个“模型”角色而设计的。
• 查看sqlite中的平面API思想(http://www.sqlite.org/c3ref/funclist.html)，它仅由函数原语(C )组成。

Answer 3

我时不时地想要一个接口，首先想到的是一个大的接口。有一个通用的设计模式吗？

这是一种叫做单块类的设计反模式。在类或接口中有50个方法可能违反SRP。铁板一块的类之所以出现，是因为它试图成为每个人的一切。

DCI解决了方法臃肿。从本质上说，一个类的许多责任可以分配给角色(将其卸载到其他类)，这些角色仅在某些上下文中相关。角色的应用可以通过多种方式实现，包括mixins或装潢工。这种方法保持了类的专注和精益。

返回对象的5个方法怎么样，每个对象都有10个方法？

这建议在对象本身实例化时实例化所有角色。但是为什么要实例化您可能不需要的角色呢？相反，在实际需要它的上下文中实例化一个角色。

如果您发现向DCI重构并不明显，那么可以使用更简单的访客模式。它提供了类似的好处，而没有强调用例上下文的创建。

编辑:我在这方面的想法已经改变了一些。我提供了另一个答案。