Lors de la conception d'une structure de données, les méthodes d'assistance devraient-elles être accessibles aux autres utilisateurs?

Question

J'ai eu une conversation avec mon professeur aujourd'hui au sujet de la structure de données Chunklist sur laquelle nous travaillons. Fondamentalement, il s'agit d'un hybride d'une liste chaînée circulaire ordonnée avec chaque nœud contenant un arraylist. Comme il s'agit d'une liste ordonnée, la méthode add() est assez compliquée, j'ai donc écrit une classe imbriquée pour contenir les méthodes auxiliaires, comme diviser un morceau en deux morceaux plus petits, trouver le point d'insertion, créer un nouveau noeud, entre autres. Ces méthodes auxiliaires maintiennent la taille de la méthode à moins de 30 lignes, mais si tout était inclus, la méthode serait bien supérieure à 150 lignes.

EDIT: point de professeur clarifié

Sa position était de faire sans la classe d'aide et ont le retourner uniquement le nœud et l'index à l'intérieur, qui est utilisé par l'itérateur et ont tout le reste visible pour un point de lisibilité. J'ai construit une classe d'aide comme ListLoc<E> ll= new ListLoc();, et l'accès aux méthodes comme ll.insertItem(item) était, de son point de vue, difficile sur la lisibilité et le déroulement du programme. Ses mots "Je regarde comme un objet pour quelque chose, pas seulement des méthodes d'instance." Ma position était de savoir pourquoi ces méthodes sont visibles lorsqu'elles font partie intégrante du fonctionnement de la structure et ne devraient pas être accessibles directement. Ainsi, lors de la construction d'une structure de données personnalisée, les méthodes d'assistance devraient-elles être visibles par l'utilisateur final, même lorsqu'elles ne devraient PAS être utilisées?

Answer 1

Les rendre visibles et les cacher à l'intérieur d'une sous-classe ne sont pas nécessairement la même chose. Je suis d'accord avec votre professeur sur le fait que créer un cours dans le seul but d'encapsuler des méthodes auxiliaires n'est pas la meilleure façon de procéder. Moi aussi, je m'attendrais à ce qu'une classe représente un objet que je puisse déclarer et puisse être seul.

Si tout ce que vous voulez faire est de rendre les fonctions invisibles à l'utilisateur, puis rendre ces méthodes méthodes privées. Si votre utilisateur utilise une version précompilée de la bibliothèque, vous n'avez même pas besoin de mentionner ces fonctions dans la définition de classe que vous donnez à l'utilisateur. C'est une approche beaucoup plus propre qui maintient la fonctionnalité limitée aux internes de la classe sans créer une sous-classe inutile. De plus, rappelez-vous que toutes vos fonctions d'assistance n'ont pas besoin d'être membres de la classe (du moins en C++, les autres langues peuvent varier). Vous pouvez créer des fonctions d'assistance à l'intérieur du fichier .c dans lequel vous créez vos fonctions membres et déclarer ces fonctions d'assistance static pour les limiter à la portée du fichier. D'après ce que vous avez décrit, il semble que toutes les fonctions de votre classe d'aide puissent être réduites à la taille du fichier et vous pouvez éliminer la classe supplémentaire.

Answer 2

Je ne pense pas qu'ils devraient être visibles s'ils ne peuvent pas être utilisés. Les rendre privés favorise l'hygiène dans l'API. Mais alors, ils ne devraient probablement pas être appelés «aidants» non plus.