Quelle est la limite du nombre de méthodes d'une classe?

Dans les différents livres de conception que j'ai lus, l'accent est parfois mis sur le nombre de méthodes qu'une classe doit avoir (en considérant un langage OO, comme java ou C # par exemple). Souvent, les exemples rapportés dans ces livres sont très nets et simples, mais rarement ils couvrent un cas «grave» ou complexe.
Cependant, la plage semble se situer entre 5 et 8.

Dans un projet, j'ai développé une classe "Note", avec son attribut comme propriétés: Title, Desctiption, CreateDate, etc.
Puis quelques méthodes de base comme: getRelations (si la note est affectée à différents documents), getExpiryDate, ect.

Cependant, dans le développement de l'application, plus de fonctionnalités étaient nécessaires, et donc plus de méthodes.

Je sais que moins une classe a de méthodes, plus elle est couplée de manière lâche. C'est en effet un bon avantage en termes de modularité et de réutilisabilité, plus facile à éditer.
Soit dit en passant, si dans notre contexte il n'y a pas besoin (ni même de sens) de créer des sous-classes et que toutes les fonctions nécessaires sont liées à cette classe, combien de méthodes pouvons-nous encore attacher?

Je suis d'accord avec le fait d'avoir plus de 15 méthodes, alors peut-être qu'une petite refonte pourrait être nécessaire.
Mais même dans ce cas, si la suppression de certaines méthodes ou de l'héritage n'est pas une option, quelle serait la bonne façon?

Ayez autant de méthodes que nécessaire. J'essaierais de limiter le nombre de méthodes publiques à cette règle 5-8 si possible. Honnêtement, la plupart des gens ont le problème opposé où ils ont des super-méthodes folles qui doivent être disséminées plus, pas moins. Peu importe le nombre de méthodes d'assistance privées dont vous disposez. En fait, si vous restiez en dessous de 8 méthodes en Java, vous pouviez atteindre la limite avec une classe qui n'avait qu'un constructeur, un toString et le getter / setter pour 3 propriétés ... ce qui n'est pas exactement une classe robuste. En fin de compte, ne vous inquiétez pas du nombre de méthodes de votre classe. Vous vous inquiétez de vous assurer que votre classe ne prend pas en charge des problèmes non liés et que vous disposez d'une interface publique raisonnable avec des méthodes faciles à comprendre.

La réponse est vraiment simple: mettez tout dans une classe qui appartient à ses responsabilités, mais soyez prudent lors de l'attribution des responsabilités.

Parfois, une grande classe est composée de classes plus petites avec des responsabilités différentes.

En général, j'essaie de diviser les responsabilités en classes plus petites lorsque la classe devient difficile à utiliser ou à entretenir. J'ai rarement des cours de plus de 500 lignes. Mes plus grandes classes ont environ 1.5k locs.

Vous ne pouvez tout simplement pas énoncer une règle générale comme "une classe doit avoir entre n et m méthodes".

Il n'y a aucune raison (dans la conception OO) d'avoir seulement autant de méthodes. Il n'est pas vrai non plus qu'une classe avec moins de méthodes soit mieux découplée.

Regardez la classe java.lang.String, par exemple. Beaucoup de méthodes, car il y a tellement de choses que l'on peut faire avec une chaîne. Néanmoins pas fortement couplé.

Je me demande pourquoi un nombre magique comme 15 pourrait séparer le bon et le mauvais design. Non, ce n'est pas si simple.

Dans PMD, le comportement par défaut de la règle TooManyMethods consiste à identifier et à marquer les classes avec 10 méthodes ou plus comme erreurs potentielles. Ce n'est cependant qu'un nombre arbitraire. C'est facilement changé dans une configuration. Indépendamment de ce que ce nombre est, c'est juste un indicateur pour qu'un développeur regarde une classe et voit s'il y a un problème, pas qu'il y ait un problème avec elle.

Quelque chose d'un peu plus concret pourrait être la règle 7 plus / moins 2 . Cela indique que l'esprit humain peut contenir et comprendre entre 5 et 9 «objets» en mémoire. Lors de la lecture d'une classe particulière, les objets seraient très probablement les méthodes et les champs qui composent cette classe. Cependant, les classes ont souvent plus de 9 champs et méthodes, même si vous ne comptez pas accesseurs, mutators et toutes les opérations standard (par exemple toString(), hashCode()et equals()en Java).

Les mesures les plus pertinentes seraient le fan-in et le fan-out et les discussions sur le couplage et la cohésion . Le principe de la responsabilité unique et la séparation des préoccupations doivent être appliqués - une classe doit faire ou représenter une chose et une seule chose. Celles-ci sont bien meilleures que d'essayer d'attribuer des nombres à un nombre maximum / minimum de méthodes lors de l'évaluation d'une conception ou d'une mise en œuvre.