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

22

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

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

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

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

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

Francesco
источник
3
Люди, кажется, имеют встроенный диапазон забывания. Как только вы получите последние семь вариантов, первые несколько начнут забываться. Так что не давайте людям больше 7 вариантов на интерфейс.
Мартин Йорк,
+ 1 @ Мартин- 7 + или- 2
Морган Херлокер
Это ограничение только для кратковременной памяти. Иначе как мы могли бы вспомнить все эти разные буквы и слова? Серьезно, если класс будет интенсивно использоваться, вы можете думать о нем как о мини-языке и иметь столько методов, сколько вам нужно, чтобы выразить все, что вам нужно с ним делать.
Артем

Ответы:

30

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

Морган Херлокер
источник
Правильно, но если это служебный класс, то до 10-15 это нормально.
Сид
1
@SidCool - я не говорю, что никогда не использую их, но служебные классы на самом деле не лучшая практика для начала. Как правило, это просто мини-класс богов, который объединяет кучу не связанных между собой проблем. Имея это в виду, служебный класс на самом деле вообще не должен существовать, тем более с 15 методами.
Морган Херлокер
1
Мой класс «Примечание» не является служебным классом. Он представляет бизнес-объект (примечание, которое может добавлять комментарии и описание к документу). Однако я согласен с Ironcode в отношении опасности «служебных» классов. Они приходят на помощь, когда мы спешим с нашими сроками доставки, но я думаю, что часто для них есть лучшее решение / дизайн.
Франческо
13

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

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

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

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

сокол
источник
8

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

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

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

Инго
источник
Я согласен, число 15 было лишь приблизительным значением, полученным при чтении этих книг по проектированию (например, «Завершенный код» Стивена Макконнелла). Действительно, у класса String есть множество методов, и все они реализованы в одной и той же сущности.
Франческо
@Luca: Проблема с некоторыми из этих книг заключается в том, что примеры часто надуманные и поэтому меньше, чем многие примеры из реального мира.
FrustratedWithFormsDesigner
Точно ... вероятно, чтобы сделать концепции более понятными для большинства и расширить потенциальную базу покупателей тоже ...
Франческо
Я хочу видеть любой вид DataGrid или даже элемент управления пользовательского интерфейса только с 15 методами. Если вы разделите эти классы на более мелкие, то интерфейс станет кошмаром.
Сокол
6

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

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

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

Томас Оуэнс
источник
+1 - правило 7 + -2 - это правило, в соответствии с которым используется юзабилити.
Морган Херлокер