Сколько классов на пакет? методы в классе? линии по методу?

Я должен дать общее замечание о каком-то огромном проекте Java, для которого у меня мало видимости, и мне было интересно, существуют ли какие-либо рекомендации для определения:

какое количество классов в пакете можно считать правильным, низким или высоким (этот проект имеет 3,89 класса на пакет, что для меня немного мало),
количество методов в классе? (этот проект имеет 6.54 метода для каждого класса...
количество строк в одном методе? (этот проект имеет около 7 строк в каждом методе (кажется мне очень хорошо, может быть, немного ниже))

Я должен отметить, что этот вопрос касается только волюметрии. У меня есть куча отчетов из качественных инструментов (checkstyle, jdepend, cpd, pmd, ncss), которые дают мне больше видения избыточности кода, использования классов, ошибок и т.д.

Ответ 1

Стив Макконнелл в своей книге Code Complete рекомендует около 7 методов для каждого класса, и больше строк в методе затем не просматривается на одном экране без прокрутки.

Я не уверен в классах на пакет.

Я бы очень рекомендовал прочитать Code Complete для получения дополнительной информации по таким темам.

Ответ 2

Я думаю, что такие статистики довольно бесполезны, как знание строк в методе показывает, будет ли оно использоваться каким-либо проектом или нет; я думаю, вы должны смотреть больше по следующим направлениям:

Включите ли ваши пакеты как классы?
Действуют ли ваши классы как субъект самостоятельно?
Сделайте методы внутри функции классов правильно и эффективно?

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

Ответ 3

Роберт С. Мартин, недавно выпустивший книгу "Чистый код", утверждает, что количество линий на метод должно быть абсолютно минимальным. Между 1-7 линиями хорошее правило.

В книге "ThoughtWorks Anthology" также содержится замечание в эссе "Object Calisthenics" Джеффа Бэй. Он предлагает 9 довольно жестких ограничений, которые сделают вас лучшим разработчиком OO в долгосрочной перспективе. Подробнее о них здесь.

Чтобы ответить на ваши конкретные вопросы, это конкретные ограничения для вас: - не более 10 классов на упаковку - Максимум 50 строк в классе

Эти ограничения могут быть не идеальными для всех ваших реальных проектов, но использование их в небольшом (хобби?) проекте заставит вас лучше практиковать.

Ответ 4

К сожалению, нет абсолютного (объективного) понятия качества в программном обеспечении. Таким образом, для них нет "правильного" значения. Однако здесь есть две (личные) обсервации:

3,89 класса/пакета очень низки. Это означает, что вы будете сражаться через сложное дерево пакетов.

7 Линии на метод: Действительно звучит хорошо. Однако, если эти числа были получены в результате преднамеренных усилий по сокращению количества строк в методах, вы могли бы столкнуться с одной логической задачей, распространяющейся по нескольким частным методам, что затруднит понимание класса ( в некоторых случаях). Фактически в CodeComplete-2 автор приводит исследование, в котором было обнаружено, что длина метода гораздо менее важна, чем его циклическая сложность и уровень ее вложенности.

Ответ 5

В полезном руководстве по дизайну говорится, что каждый класс должен делать только одно дело и делать это хорошо. Это не даст вам фиксированного количества методов для каждого класса, но оно ограничит число и упростит понимание и поддержку класса.

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

Ответ 6

(примечание: tl; dr доступно в самом низу для моего реального мнения)

Я не буду приводить какое-либо большое имя и сказать, что правильный ответ, потому что он всегда очень зависит от вас, как вы делаете все это. Например, количество методов: если вы создаете управляющее программное обеспечение для современного HD-телевизора с дистанционным управлением с ЖК-дисплеем, которое имеет около 40-50 кнопок, как вы можете разбить это на классы согласованно, чтобы вы только имеют, например, 7 методов в классе?

Лично мне нравится поддерживать все методы одного уровня доступа в одном классе, что означает, что некоторые классы полезности могут в итоге иметь сотни методов, но, по моему мнению, легче сделать что-то вроде StringUtil.escapeXMLspecialCharacters(someString), чем StringUtil.XML.escapeSpecialCharacters(someString) или XMLUtil.escapeSpecialCharacters(someString). Несмотря на то, что все эти решения выглядят как ОК, первый из них процветает (по крайней мере, на мой взгляд, это!), Потому что это простой и простой способ получить доступ к этому методу: вам не нужно думать, что строка, которую вы обрабатываете, содержит XML или XHTML или JSON или что-то еще, вы просто выберите один метод из общей группы методов и что он.

Сохраняя предыдущую аналогию с удаленным телевизором, давайте предположим, что вы все равно разделите их на разные классы. Если мы позволяем себе иметь 7 таких методов для каждого класса в среднем и управлять группировкой кнопок на пульте дистанционного управления с такими чувствительными группами, как MenuButtons, AdjustmentButtons и 'NumberSelectorButtons', мы получаем 8 или около того классов. На самом деле это не так, но это немного сбивает с толку, особенно если они не очень разделены на чувствительные группы. Представьте себе, что в вашем офисе TVRemotes'R'Us Inc. говорят: "Кто говорит, что кнопка включения/выключения питания является кнопкой управления?" "Кто джокер, который добавляет кнопки громкости +/- в меню? PRE/CH (кнопка, которая переключается между текущим и предыдущим каналом и/или источником изображения) не является цифровой кнопкой!" "Направляющая кнопка открывает навигационное меню и навигационное меню в зависимости от контекста, что мы будем с ним делать!"

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

Прежде чем я запишу последние два цента, одна вещь о количестве строк в методе: подумайте о коде как блоках. Каждый цикл является блоком, каждое условие является блоком и т.д. И т.д. Какова минимальная сумма этих блоков, необходимых для единицы кода, которая несет единую ответственность? Это должен быть ваш лимитер, а не желание иметь "Семь повсюду". от количества классов в пакете, методов в классах и строк кода в методах.

И здесь TL; DR:

Итак, мое настоящее мнение на самом деле таково: количество классов в пакете должно быть довольно низким. Я в последнее время начинаю делать следующее, но я не уверен, буду ли я продолжать:

Пакет foo содержит интерфейсы и другие общие классы для реализаций.
Пакет foo.bar содержит реализацию указанных интерфейсов для функции bar
Пакет foo.baz содержит реализацию указанных интерфейсов для функции baz

Это обычно означает, что вся моя структура имеет когерентное (и, скорее всего, низкое) количество классов, и, читая интерфейсы класса верхнего уровня (и их комментарии), я также должен понимать другие пакеты.

Методы для каждого класса: все, что необходимо, как я объяснял выше. Если ваш класс не может жить без 170 методов, то пусть это будет им. Рефакторинг - это добродетель, а не то, что можно применять все время.

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