Какой предел N максимальных методов вы разрешаете в своих классах? - PullRequest
3 голосов
/ 16 марта 2009

Заполняя Обследование объектно-ориентированных концепций (Чтобы предоставить некоторым академическим исследователям реальные данные о разработке программного обеспечения), я столкнулся с этим вопросом:

Какое максимальное количество N методов вы разрешаете в своих классах?

Затем опрос продолжает спрашивать, реорганизуете ли вы свои классы, как только достигнете этого предела N.

Честно говоря, я никогда не задумывался о таком пределе при разработке своих приложений, и удивляюсь, в чем причина этого. Зачем мне хотеть самостоятельно навязывать себе произвольное число, которое, вероятно, очень зависит от функциональности классов?

Ответы [ 5 ]

8 голосов
/ 16 марта 2009

Вам не нужно ограничивать N максимумов. Но вы должны следовать принципу «Высокой сплоченности». И не создавайте классы "все может делать что угодно".

Полагаю, есть немного N, после которого вы должны начать беспокоиться. Но это действительно зависит от самого класса и его основной цели.

4 голосов
/ 16 марта 2009

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

Тем не менее, если у вас в классе более 20 или около того, есть большая вероятность, что он делает слишком много и нарушает SRP .

3 голосов
/ 16 марта 2009

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

Кроме того, у хорошо спроектированного класса может быть 30 методов, а у плохо спроектированного может быть 3 (Умм, 30 толкает его, но суть в том, что это не обязательно даже хорошая метрика, вроде как считая kloc)

Ваш каркас / язык может потребовать множество методов и без бизнес-логики.

Подсчет количества нетривиальных методов с бизнес-логикой в ​​них может быть интересным - я бы сказал, что около 4 или 5 будет уместно.

Я был удивлен, сколько методов в действительности имеют классы JDK, когда я смотрел на исходный код, но они настолько хорошо разбиты, настолько малы и так легко читаются, что вообще не было проблем с их использованием. .

3 голосов
/ 16 марта 2009

Я бы тоже не стал устанавливать произвольные ограничения, но я бы сказал, что как только у класса будет больше, чем где-то в диапазоне 10-20 открытых методов, я бы серьезно посмотрел, что делает этот класс. Еще во времена J2EE мы называли их Enterprise Java Melons.

То же правило применяется к длине отдельных методов. Я видел классы, которые имели только один или два метода, но каждый из этих методов был сотнями строк кода.

1 голос
/ 16 марта 2009

Как и другие отмечали, что, как правило, не существует произвольного числа методов, и в этот момент я скажу: «Это слишком много методов!» Иногда противоположность может быть такой же плохой, как, например, когда у объекта есть монолитный метод «все», охватывающий сотни строк.

При этом, если я открою исходный файл, на который раньше не смотрел, и увижу более 10-20 методов, я, вероятно, отсканирую его, чтобы выяснить, нельзя ли каким-то образом его повторно проанализировать.

...