En conception de classe, est-ce une mauvaise habitude si une méthode appelle une autre méthode dans la même classe (par exemple, 3 méthodes appellent 1 méthode dans la même classe).Méthodes appelant d'autres méthodes dans la même classe
Merci
Non. En fait, c'est une bonne pratique de le faire. Ou pensez-vous que vos trois méthodes qui font l'appel devraient chacune dupliquer le code appelé?
Les méthodes ne sont que les fonctions et les fonctions sont des abstractions utiles pour la réutilisation du code et l'amélioration de la conception. Si trois méthodes d'une classe doivent faire la même chose pendant l'exécution, doivent-elles copier-coller le code pour cela ou appeler une méthode séparée? Avoir une partie signifiante de code séparée en une méthode appelée par d'autres méthodes est juste un autre exemple de réutilisation de code, ce qui est bien sauf si vous en faites vraiment trop.
Non. Il semble que vous ayez trouvé une utilisation valide pour maintenir DRY principles.
Pas du tout. En fait, tout le contraire. Les méthodes sont là pour accomplir des tâches spécifiques, et vous devriez les utiliser précisément pour cela.
Pas du tout, c'est normal si vous avez correctement conçu vos classes. Vous devriez avoir une petite interface publique, et si l'implémentation est complexe, vous finirez probablement par appeler de nombreuses méthodes privées dans la même classe.
En fait, et non cela peut être un anti-pattern. Si vous appelez constamment des méthodes d'une autre classe, cela s'appelle Feature Envy et vous devriez probablement combiner des classes. Si vous mettez toute la mise en œuvre dans une fonction gargantuesque, c'est tout simplement impossible à maintenir, et contient probablement beaucoup de duplication de code.
Casser des choses dans d'autres méthodes réutilisables est une bonne chose. Votre cas de 3 méthodes appelant le même est la réutilisation parfaite du code. Ce serait très mauvais si le code de cette fonction était dupliqué dans chacune des fonctions d'appel.
Oui, si ces méthodes sont substituables, c'est-à-dire si la classe et/ou les méthodes ne sont pas définitives. La raison en est que les sous-classes qui tentent de remplacer le comportement ou de fournir une couche de service ne peuvent pas le faire de manière fiable, car la couche peut être saisie plusieurs fois. Exemple (Scala code pseudo) où nous partons du principe que HashSet.addAll appelle son propre HashSet.add:
class MemCountingSet[T] extends HashSet[T] {
private def sizeOf(t: T) = ...
private var memCount = 0
def add(t: T) = {
memCount += sizeOf(t)
super.add(t)
}
def addAll(coll: Collection[T]) = {
memCount += coll.foreach(sizeOf)
super.addAll(coll)
}
}
Lorsque vous utilisez addAll nous nous retrouvons maintenant le double comptage.