Qual é o limite para o número de métodos de uma classe?

Nos diferentes livros de design que eu li, às vezes é dada grande ênfase ao número de métodos que uma classe deve ter (considerando uma linguagem OO, como java ou C #, por exemplo). Freqüentemente, os exemplos relatados nesses livros são muito claros e simples, mas raramente cobrem um caso "sério" ou complexo.
No entanto, o intervalo parece estar entre 5 e 8.

Em um projeto, desenvolvi uma classe "Note", com seu atributo como propriedades: Title, Desctiption, CreateDate, etc.
Em seguida, alguns métodos básicos como: getRelations (se a nota estiver atribuída a documentos diferentes), getExpiryDate, ect.

No entanto, prosseguindo no desenvolvimento do aplicativo, foram necessárias mais funcionalidades e, portanto, mais métodos.

Eu sei que quanto menos métodos uma classe tiver, mais fracamente acoplada será. Essa é realmente uma boa vantagem em termos de modularidade e reutilização, além de mais fácil de editar.
A propósito, se em nosso contexto não há necessidade (ou mesmo sentido) de criar subclasses e todas as funções necessárias estão relacionadas a essa classe, quantos métodos podemos anexar ainda mais?

Concordo que, com mais de 15 métodos, talvez seja necessário um novo design.
Mas mesmo nesse caso, se a exclusão de alguns dos métodos ou herança não é uma opção, qual seria o caminho correto?

Tenha quantos métodos você precisar. Eu tentaria manter o número de métodos públicos nessa regra de 5 a 8, se possível. Honestamente, a maioria das pessoas tem o problema oposto, onde eles têm super-métodos malucos que precisam ser quebrados mais, não menos. Realmente não importa quantos métodos auxiliares particulares você tenha. De fato, se você ficasse abaixo de 8 métodos em Java, poderia atingir o limite com uma classe que tinha apenas um construtor, um toString e o getter / setter por 3 propriedades ... o que não é exatamente uma classe robusta. A linha inferior é, não se preocupe com quantos métodos sua classe é. Preocupe-se em garantir que sua classe não assuma preocupações não relacionadas e que você tenha uma interface pública razoável que possua métodos fáceis de entender.

A resposta é realmente simples: coloque tudo em uma classe que pertença a suas responsabilidades, mas tenha cuidado ao atribuir responsabilidades.

Às vezes, uma classe grande é um composto de classes menores com responsabilidades diferentes.

Em geral, tento dividir as responsabilidades em classes menores quando a classe se torna pesada no uso ou na manutenção. Raramente tenho aulas com mais de 500 linhas. Minhas maiores classes têm aproximadamente 1.5k locs.

Você simplesmente não pode declarar uma regra geral como "uma classe deve ter entre os métodos n e m".

Não há razão (no design do OO) para ter apenas tantos métodos. Também não é verdade que uma classe com menos métodos seja melhor dissociada.

Veja a classe java.lang.String, por exemplo. Muitos métodos, porque há muitas coisas que podemos fazer com uma string. No entanto, não está fortemente associado.

Eu me pergunto por que um número mágico como 15 poderia separar um design bom e um ruim. Não, não é assim tão fácil.

No PMD, o comportamento padrão da regra TooManyMethods é identificar e sinalizar classes com 10 ou mais métodos como possíveis erros. Este é apenas um número arbitrário, no entanto. É facilmente alterado em uma configuração. Independentemente de qual seja esse número, é apenas um sinalizador para um desenvolvedor analisar uma classe e ver se há um problema, não que exista um problema com ele.

Algo um pouco mais concreto pode ser a regra dos 7 mais / menos 2 . Isto afirma que a mente humana pode reter e compreender entre 5 e 9 "objetos" na memória. Ao ler uma classe específica, os objetos provavelmente seriam os métodos e campos que compõem essa classe. No entanto, as classes freqüentemente têm mais de 9 campos e métodos, mesmo se você não contar acessores, mutators e quaisquer operações padrão (por exemplo, toString(), hashCode()eequals() em Java).

As medidas mais relevantes seriam fan-in e fan-out e discussões sobre acoplamento e coesão . O princípio da responsabilidade única e a separação de preocupações devem ser aplicados - uma classe deve fazer ou representar uma coisa e uma coisa sozinha. Isso é muito melhor do que tentar atribuir números ao número máximo / mínimo de métodos ao avaliar um design ou implementação.