¿Cuál es el límite para el número de métodos de una clase?

En los diferentes libros de diseño que leí, a veces se pone gran énfasis en la cantidad de métodos que debe tener una clase (considerando un lenguaje OO, como java o C #, por ejemplo). A menudo, los ejemplos reportados en esos libros son muy claros y simples, pero rara vez cubren un caso "serio" o complejo.
Sin embargo, el rango parece estar entre 5 y 8.

En un proyecto desarrollé una clase "Note", con su atributo como propiedades: Título, Desctiption, CreateDate, etc.
Luego, algunos métodos básicos como: getRelations (si la nota está asignada a diferentes documentos), getExpiryDate, ect.

Sin embargo, en el desarrollo de la aplicación, se requerían más funcionalidades y, por lo tanto, más métodos.

Sé que cuantos menos métodos tenga una clase, más vagamente acoplada estará. De hecho, es una buena ventaja en términos de modularidad y reutilización, más fácil de editar.
Por cierto, si en nuestro contexto no hay necesidad (o incluso sentido) de crear subclases y todas las funciones necesarias están relacionadas con esa clase, ¿cuántos métodos podemos adjuntar?

Estoy de acuerdo en que tener más de 15 métodos, entonces quizás se requiera un pequeño rediseño.
Pero incluso en ese caso, si eliminar algunos de los métodos o la herencia no es una opción, ¿cuál sería la forma correcta?

Ten tantos métodos como necesites. Intentaría reducir el número de métodos públicos a esa regla 5-8 si es posible. Honestamente, la mayoría de las personas tienen el problema opuesto en el que tienen súper métodos locos que necesitan ser explotados más, no menos. Realmente no importa cuántos métodos de ayuda privada tenga. De hecho, si permaneció por debajo de 8 métodos en Java, podría alcanzar el límite con una clase que solo tuviera un constructor, un toString y el getter / setter para 3 propiedades ... que no es exactamente una clase robusta. La conclusión es que no se preocupe por cuántos métodos tiene su clase. Preocúpese por asegurarse de que su clase no tome preocupaciones no relacionadas, y que tenga una interfaz pública razonable que tenga métodos fáciles de entender.

La respuesta es realmente simple: ponga todo en una clase que pertenezca a sus responsabilidades, pero tenga cuidado al asignar responsabilidades.

A veces una clase grande es un compuesto de clases más pequeñas con diferentes responsabilidades.

En general, trato de dividir las responsabilidades en clases más pequeñas cuando la clase se vuelve difícil de manejar en su uso o mantenimiento. Raramente tengo clases que tengan más de 500 líneas. Mis clases más grandes tienen aproximadamente 1.5k locs.

Simplemente no puede establecer una regla general como "una clase debería tener entre n y m métodos".

No hay ninguna razón (en el diseño OO) para tener solo tantos métodos. Tampoco es cierto que una clase con menos métodos esté mejor desacoplada.

Mire la clase java.lang.String, por ejemplo. Muchos métodos, porque hay tantas cosas que uno puede hacer con una cadena. Sin embargo, no está fuertemente acoplado.

Me pregunto por qué un número mágico como 15 podría separar el diseño bueno y el malo. No, no es tan fácil.

En PMD, el comportamiento predeterminado de la regla TooManyMethods es identificar y marcar las clases con 10 o más métodos como posibles errores. Sin embargo, este es solo un número arbitrario. Se cambia fácilmente en una configuración. Independientemente de cuál sea este número, es solo una señal para que un desarrollador vea una clase y vea si hay un problema, no es que haya un problema con él.

Algo que es un poco más concreto podría ser la regla 7 más / menos 2 . Esto afirma que la mente humana puede retener y comprender entre 5 y 9 "objetos" en la memoria. Al leer una clase en particular, los objetos probablemente serían los métodos y campos que conforman esa clase. Sin embargo, las clases con frecuencia tienen más de 9 campos y métodos, incluso si no se cuenta descriptores de acceso, mutators y cualquier operación estándar (por ejemplo, toString(), hashCode(), y equals()en Java).

Las medidas más relevantes serían de fan-in y fan-out y discusiones de acoplamiento y cohesión . Se debe aplicar el principio de responsabilidad única y la separación de preocupaciones : una clase debe hacer o representar una cosa y una sola cosa. Estos son mucho mejores que tratar de asignar números al número máximo / mínimo de métodos al evaluar un diseño o implementación.