Qual è il limite al numero di metodi di una classe?

In diversi libri di design che ho letto, a volte viene posta grande enfasi sul numero di metodi che una classe deve avere (considerando un linguaggio OO, come java o C # per esempio). Spesso gli esempi riportati in quei libri sono molto chiari e semplici, ma raramente coprono un caso "serio" o complesso.
Tuttavia, l'intervallo sembra essere compreso tra 5 e 8.

In un progetto ho sviluppato una classe "Note", con il suo attributo come proprietà: Title, Desctiption, CreateDate, ecc.
Quindi alcuni metodi di base come: getRelations (se la nota è assegnata a documenti diversi), getExpiryDate, ect.

Tuttavia, procedendo nello sviluppo dell'applicazione, erano necessarie più funzionalità e, quindi, più metodi.

So che meno metodi ha una classe, più è liberamente accoppiata. Questo è davvero un buon vantaggio in termini di modularità e riusabilità, più facile da modificare.
A proposito, se nel nostro contesto non è necessario (o addirittura senso) creare sottoclassi e tutte le funzioni necessarie sono correlate a quella classe, quanti metodi possiamo ulteriormente collegare?

Concordo sul fatto che avere più di 15 metodi, forse potrebbe essere necessaria una piccola riprogettazione.
Ma anche in quel caso, se la cancellazione di alcuni dei metodi o dell'ereditarietà non è un'opzione, quale sarebbe la strada giusta?

Hai tutti i metodi di cui hai bisogno. Proverei a mantenere il numero di metodi pubblici a quella regola 5-8 se possibile. Onestamente, la maggior parte delle persone ha il problema opposto in cui hanno dei super-metodi pazzi che devono essere sviluppati di più, non di meno. Non importa davvero quanti metodi di supporto privato hai. In effetti, se rimanessi al di sotto di 8 metodi in Java, potresti raggiungere il limite con una classe che aveva solo un costruttore, un toString e il getter / setter per 3 proprietà ... che non è esattamente una classe robusta. La linea di fondo è, non preoccuparti di quanti metodi è la tua classe. Preoccupati di assicurarti che la tua classe non si occupi di questioni non correlate e che tu abbia un'interfaccia pubblica ragionevole con metodi facili da capire.

La risposta è davvero semplice: metti tutto in una classe che appartiene alle sue responsabilità, ma fai attenzione quando assegni le responsabilità.

A volte una grande classe è un composto di classi più piccole con responsabilità diverse.

In generale, provo a dividere le responsabilità in classi più piccole quando la classe diventa ingombrante nel suo utilizzo o nella manutenzione. Raramente ho classi più lunghe di 500 righe. Le mie classi più grandi hanno approssimativamente 1.5k loc.

Semplicemente non puoi dichiarare una regola generale come "una classe dovrebbe avere tra n e m metodi".

Non c'è motivo (nella progettazione di OO) per avere solo così tanti metodi. Inoltre, non è vero che una classe con meno metodi sia meglio disaccoppiata.

Guarda la classe java.lang.String, per esempio. Molti metodi, perché ci sono così tante cose che si possono fare con una stringa. Tuttavia non accoppiato fortemente.

Mi chiedo perché un numero magico come 15 possa separare il design buono da quello cattivo. No, non è così facile.

In PMD, il comportamento predefinito della regola TooManyMethods consiste nell'identificare e contrassegnare le classi con 10 o più metodi come potenziali errori. Questo è solo un numero arbitrario, però. È facilmente cambiato in una configurazione. Indipendentemente da cosa sia questo numero, è solo una bandiera per uno sviluppatore guardare una classe e vedere se c'è un problema, non che ci sia un problema.

Qualcosa che è un po 'più concreto potrebbe essere la regola 7 più / meno 2 . Questo afferma che la mente umana può contenere e comprendere tra 5 e 9 "oggetti" in memoria. Quando si legge una classe particolare, gli oggetti sarebbero molto probabilmente i metodi e i campi che compongono quella classe. Tuttavia, le classi hanno spesso più di 9 campi e metodi, anche se non si contano di accesso, mutator e le eventuali operazioni standard (ad esempio, toString(), hashCode(), e equals()in Java).

Le misure più pertinenti sarebbero il fan-in e il fan-out e le discussioni sull'accoppiamento e sulla coesione . L' unico principio responsabilità e separazione degli interessi dovrebbero essere applicate - una classe deve fare o rappresentare una cosa e una cosa sola. Questi sono molto meglio che cercare di assegnare numeri al numero massimo / minimo di metodi quando si valuta un progetto o un'implementazione.