在设计数据结构时，其他用户是否可以访问辅助方法？

Question

我今天和我的教授谈了一下我们一直在研究的Chunklist数据结构的布局。基本上，它是有序循环链表的混合，每个节点都包含一个arraylist。

由于这是一个有序列表，add（）方法非常复杂，所以我编写了一个嵌套类来保存辅助方法，例如将一个块拆分成两个较小的偶数块，找到插入点，创建一个新的节点，等等。这些辅助方法将方法的大小保持在30行以下，但如果包含所有内容，则一种方法将超过150行。

编辑：澄清了教授的观点

他的立场是没有辅助类，并且只返回其中的节点和索引，迭代器使用该节点和索引，并且其他所有内容都是可见的。我构建了一个辅助类ListLoc<E> ll= new ListLoc();，从他的观点来看，访问方法ll.insertItem(item)对可读性和程序流程来说很困难。他的话“我希望将其作为某种东西的对象，而不仅仅是实例方法。”我的立场是为什么这些方法在结构操作中不可或缺时可见，不应直接访问。

因此，在构建自定义数据结构时，即使最终用户不应该使用辅助方法，它们是否应该可见？

Answer 1

使它们可见并将它们隐藏在子类中并不一定是一回事。我同意你的教授一致认为，创建一个仅用于封装辅助方法的类并不是最好的方法。我也期望一个类代表一个我可以声明并且可以独立存在的对象。

如果您只想让用户看不到函数，那么请将这些方法设为私有方法。如果您的用户使用的是库的预编译版本，您甚至不必在为用户提供的类定义中提及这些函数。这是一种更清晰的方法，可以将功能限制在类的内部，而不会创建不必要的子类。

另外，请记住，所有辅助函数都不必是该类的成员（至少在C ++中不是这样，其他语言可能会有所不同）。您可以在创建成员函数的.c文件中创建辅助函数，并声明这些辅助函数static以将它们限制为文件范围。根据您的描述，听起来您的助手类中的所有函数都可以下拉到文件范围，您可以消除额外的类。

Answer 2

如果不能使用它们，我认为它们不应该是可见的。私有化可以促进API的卫生。但是他们也许不应该被称为“助手”。