Яка межа обмеження кількості методів класу?

У різних книгах з дизайну, які я читаю, іноді великий акцент робиться на кількості методів, якими повинен володіти клас (враховуючи мову OO, наприклад, java або C #). Часто приклади, які повідомляються в цих книгах, дуже акуратні та прості, але рідко вони охоплюють "серйозний" чи складний випадок.
Однак, здається, діапазон знаходиться між 5 і 8.

У проекті я розробив клас "Примітка" з його attribuse як властивості: Title, Desctiption
, CreateDate і т.д.

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

Я знаю, що чим менше методів у класу, тим воно вразливіше. Це дійсно гарна перевага з точки зору модульності та повторного використання, а також легше редагувати.
До речі, якщо в нашому контексті немає необхідності (або навіть сенсу) створювати підкласи і всі необхідні функції пов'язані з цим класом, скільки методів ми можемо додатково приєднати?

Я погоджуюся, що, маючи більше 15 методів, можливо, може знадобитися трохи переробити дизайн.
Але навіть у тому випадку, якщо вилучення деяких методів чи спадкування не є варіантом, який би був правильний спосіб?

Майте стільки методів, скільки вам потрібно. Я б спробував зменшити кількість публічних методів, щоб це правило було 5-8, якщо це можливо. Чесно кажучи, у більшості людей є протилежна проблема, коли у них є шалені супер-методи, які потрібно розбити більше, а не менше. Це насправді не має значення, скільки у вас є приватних помічників. Насправді, якщо ви залишилися нижче 8 методів у Java, ви можете досягти ліміту класом, у якому були лише конструктор, toString та getter / setter для 3 властивостей ... що не є абсолютно надійним класом. Суть полягає в тому, що не переживайте про те, скільки методів у вашому класі. Турбуйтеся про те, щоб ваш клас не брав на себе непов’язані проблеми, і що у вас є розумний публічний інтерфейс, який має легкі для розуміння методи.

Відповідь насправді проста: поставте все до класу, що належить до його обов'язків, але будьте обережні при розподілі обов'язків.

Іноді великий клас - це склад менших класів з різними обов'язками.

Взагалі, я намагаюся розділити обов'язки на менші класи, коли клас стає невибагливим у використанні чи обслуговуванні. У мене рідко є заняття, довші 500 рядків. У моїх найбільших класах приблизно 1,5 тисячі локусів.

Ви просто не можете вказати загальне правило, наприклад, "клас повинен мати між n та m методами".

Немає жодних підстав (в дизайні ОО), щоб існувати лише стільки методів. Також не вірно, що клас з меншими методами краще відокремлювати.

Подивіться, наприклад, клас java.lang.String. Багато методів, тому що існує так багато речей, які можна зробити за допомогою рядка. Тим не менш, не сильно з'єднані.

Цікаво, чому магічне число, як 15, може розділити хороший і поганий дизайн. Ні, це не так просто.

У PMD поведінка за замовчуванням правила TooManyMethods полягає у визначенні та позначенні класів з 10 або більше методів як потенційних помилок. Це лише довільне число. Це легко змінюється в конфігурації. Незалежно від того, що це число, розробник - це лише прапор, щоб подивитися на клас і побачити, чи є проблема, а не те, що з цим є проблема.

Щось дещо конкретніше може бути правилом 7 плюс / мінус 2 . Це говорить про те, що людський розум може зберігати і осягати між 5 і 9 "предметами" в пам'яті. Читаючи певний клас, об'єктами, швидше за все, будуть методи та поля, що складають цей клас. Тим НЕ менше, класи часто мають більше 9 полів і методів, навіть якщо не брати до уваги аксессор, мутаторов і будь-які стандартні операції (наприклад, toString(), hashCode(), і equals()в Java).

Найбільш релевантними заходами були б приєднання та роздуття та обговорення зв'язку та згуртованості . Єдиний принцип відповідальності і поділ завдань слід застосовувати - клас повинен робити або представляти одне і тільки одне. Це набагато краще, ніж намагатися призначити числа максимальній / мінімальній кількості методів при оцінці дизайну чи реалізації.