Какое ограничение на количество методов класса?

В различных книгах по дизайну, которые я читаю, иногда большое внимание уделяется количеству методов, которые должен иметь класс (с учетом языка ОО, например, Java или C #). Часто примеры, приведенные в этих книгах, очень аккуратны и просты, но редко они охватывают «серьезный» или сложный случай.
Однако диапазон, кажется, между 5 и 8.

В проекте я разработал класс «Примечание» с его атрибутом в виде свойств: Заголовок, Описание, CreateDate и т. Д.
Затем некоторые основные методы, такие как: getRelations (если примечание назначено различным документам), getExpiryDate, ect.

Однако при разработке приложения требовалось больше функциональных возможностей и, следовательно, больше методов.

Я знаю, что чем меньше методов у класса, тем более беспорядочно он связан. Это действительно хорошее преимущество с точки зрения модульности и возможности повторного использования, а также простота редактирования.
Кстати, если в нашем контексте нет необходимости (или даже смысла) создавать подклассы и все необходимые функции связаны с этим классом, сколько методов мы можем присоединить?

Я согласен, что при наличии более 15 методов, возможно, потребуется немного изменить дизайн.
Но даже в этом случае, если удаление некоторых методов или наследования не является вариантом, какой будет правильный путь?

Имейте столько методов, сколько вам нужно. Я постараюсь уменьшить количество открытых методов до этого правила 5-8, если это возможно. Честно говоря, у большинства людей есть противоположная проблема, когда у них есть сумасшедшие супер-методы, которые нужно использовать больше, а не меньше. Это действительно не имеет значения, сколько у вас есть частных вспомогательных методов. На самом деле, если вы оставляете ниже 8 методов в Java, вы можете достичь предела с помощью класса, у которого есть только конструктор, toString и метод получения / установки для 3 свойств ... который не совсем устойчивый класс. Суть в том, что не беспокойтесь о том, сколько методов в вашем классе. Беспокоитесь о том, чтобы убедиться, что у вашего класса нет проблем, связанных с этим, и что у вас есть разумный общедоступный интерфейс, который имеет простые для понимания методы.

Ответ очень прост: поместите в класс все, что относится к его обязанностям, но будьте осторожны при распределении обязанностей.

Иногда большой класс представляет собой совокупность небольших классов с разными обязанностями.

В общем, я пытаюсь разделить обязанности на более мелкие классы, когда класс становится громоздким в использовании или обслуживании. У меня редко бывают классы длиной более 500 строк. Мои самые большие классы имеют примерно 1,5 тыс. Лок.

Вы просто не можете сформулировать общее правило типа «класс должен иметь между n и m методами».

Нет никакой причины (в дизайне ОО) иметь так много методов. Также неверно, что класс с меньшим количеством методов лучше отделен.

Посмотрите на класс java.lang.String, например. Множество методов, потому что есть очень много вещей, которые можно сделать со строкой. Тем не менее сильно не связаны.

Интересно, почему магическое число, подобное 15, могло разделить хороший и плохой дизайн? Нет, это не так просто.

В PMD стандартное поведение правила TooManyMethods состоит в том, чтобы идентифицировать и пометить классы с 10 или более методами как потенциальные ошибки. Это просто произвольное число, хотя. Это легко изменить в конфигурации. Независимо от того, что это за число, для разработчика это просто флаг, чтобы посмотреть на класс и посмотреть, есть ли проблема, а не то, что есть проблема с ним.

Что-то более конкретное может быть правилом 7 плюс / минус 2 . Это говорит о том, что человеческий разум может удерживать и понимать от 5 до 9 «объектов» в памяти. При чтении определенного класса объектами, скорее всего, будут методы и поля, составляющие этот класс. Тем не менее, классы часто имеют более 9 полей и методов, даже если не считать аксессоров, мутаторов и любые стандартные операции (например, toString(), hashCode(), и equals()в Java).

Наиболее значимыми мерами будут разветвление и разветвление, а также обсуждение взаимосвязи и сплоченности . Единый принцип ответственности и разделение задач следует применять - класс должен делать или представлять одно и только одно. Это гораздо лучше, чем пытаться присвоить номера максимальному / минимальному количеству методов при оценке проекта или реализации.