Сколько строк в классе слишком много в Java? [закрыто]

По вашему опыту, какое полезное практическое правило для того, сколько строк кода слишком много для одного класса в Java?

Чтобы было ясно, я знаю, что количество строк даже близко не соответствует реальному стандарту, который следует использовать для того, что должно быть в определенном классе, а что нет. Классы должны разрабатываться в соответствии с надлежащими принципами ООП (инкапсуляция и т. Д.). Тем не менее, практическое правило может обеспечить полезную отправную точку для соображений рефакторинга (т. Е. «Хммм, этот класс имеет> n строк кода; он, вероятно, не читается и выполняет паршивую работу по инкапсуляции, поэтому я мог бы захотеть посмотреть, стоит ли быть рефакторингом в какой-то момент ").

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

Вот связанный, не повторяющийся вопрос о строках для каждой функции .

Некоторые интересные метрики:

            тест на пригодность для юниоров
            ----- -------- ------ --- ------- --- ------
макс 500 498 1450 355 668 2168 5457
среднее значение 64,0 77,6 62,7 95,3 128,8 215,9 261,6
мин 4 6 4 10 20 3 12
сигма 75 76 110 78 129 261 369
файлы 90 632 1152 69 55 954 1468
Всего строк 5756 49063 72273 6575 7085 206001 384026

Я использую FitNesse в качестве эталона, потому что у меня было много общего с написанием. В FitNesse средний класс длиной 77 строк. Ни одна не длиннее 498 строк. И стандартное отклонение составляет 76 строк. Это означает, что в подавляющем большинстве классов менее 150 строк. Даже Tomcat, у которого один класс превышает 5000 строк, имеет большинство классов менее 500 строк.

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

Для меня строки кода не имеют значения в этом контексте. Все дело в количестве разных причин, по которым я бы пришел в этот класс, чтобы изменить его.

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

Тем не менее, если вы стремитесь к этому, то вы редко найдете классы более 200 строк. Они произойдут по уважительным причинам, но они будут редкими. Так что, если вы ищете метрику красного флага, то это не плохое место для начала; но сделайте это руководством, а не правилом.

Извините, но я очень удивлен, что во многих ответах говорится, что это "не имеет значения". Это очень много значит, сколько строк в классе. Почему? Учитывайте эти принципы при написании хорошего Java-кода ...

• способность быть свидетелем в суде
• когезия
• Связь
• Понятность

Классы с большим количеством строк, скорее всего, будут нарушать все эти принципы.

Для тех, кто заявил, что это «не имеет большого значения» ... насколько весело было вам пытаться понять класс, в котором более 5000 строк? Или изменить это? Если вы говорите, что это весело, у вас странная близость к боли ...

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

Мои комментарии основаны на чтении и изучении таких авторов, как Мартин Фаулер, Джошуа Блох и Миско Хевери. Они являются отличными ресурсами для консультации по написанию хорошего Java-кода.

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

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

Еще одна вещь, на которую вы можете обратить внимание, это количество открытых функций в классе. Это также может быть предупреждающим знаком.

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

Слишком много строк кода, если класс делает слишком много разных вещей. По сути, если вы следуете принципу Единой Ответственности для классов, существует предел того, насколько большой будет расти класс.

Что касается физических ограничений, которые вы можете иметь (источник: файл класса формата Java5 ):

• 65 536 констант, примененные интерфейсы, поля, методы и атрибуты - каждая. ПРИМЕЧАНИЕ: вам не хватит места, прежде чем вы исчерпаете любой из других предметов. ПРИМЕЧАНИЕ 2: атрибуты являются конструкциями файлов классов - их не следует путать с маркерами «@Attribute» (т. Е. Отладочная информация и байтовый код хранятся как отдельные атрибуты для метода).
• Каждый метод может быть 4 ГБ (32 бита) сгенерированного байтового кода. ПРИМЕЧАНИЕ: версии Java до 1.5 могут иметь только 64 КБ (16 бит) сгенерированного байтового кода для каждого метода.

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

Правильный ответ 42. Шучу.
На самом деле, максимальное рекомендуемое количество строк в классе - 2000 строк.

«Соглашения по Java-коду» с 1999 года утверждают это так:
файлы длиной более 2000 строк громоздки и их следует избегать.

Следуя соглашениям Sun / Oracle Coding со времени изобретения Java, я нашел разумное правило для строк в классе. 99% вашего Java-кода должны соответствовать ... А если он превышает 2000, просто поместите TODO на вершине, говоря, что класс нуждается в работе.

Хуже всего то, что программисты создают слишком много крошечных маленьких классов, в которых практически нет функциональности в каждом классе. Игнорируя рекомендацию «Favor Composition», программисты создают сотни наследующих классов, которые создают сложные объектные модели, которые намного хуже, чем проблема больших классов (которые, по крайней мере, обычно сохраняют функциональность с соответствующим именем класса).

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html#3043

Чистый код:

Классы должны быть маленькими!

Первое правило классов - они должны быть маленькими. Второе правило классов заключается в том, что они должны быть меньше, чем это. Нет, мы не собираемся повторять один и тот же текст из главы «Функции». Но, как и в случае с функциями, меньшее является основным правилом, когда дело доходит до проектирования классов. Как и в случае с функциями, нашим непосредственным вопросом всегда является «Как мало?»

** С помощью функций мы измерили размер путем подсчета физических линий. С классами мы используем другую меру. Мы считаем обязанности. **

Название класса должно описывать, какие обязанности он выполняет. На самом деле, наименование - это, вероятно, первый способ помочь определить размер класса. Если мы не можем получить краткое имя для класса, то оно, вероятно, слишком велико. Чем более двусмысленно имя класса, тем более вероятно, что у него слишком много обязанностей. Например, имена классов, включая такие слова, как Processor или Manager или Super, часто намекают на неудачное объединение обязанностей.

Затем:

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

В итоге вы получите класс с управляемым размером.

Количество строк - довольно плохой показатель качества класса. Мне нравится смотреть (как уже упоминали другие) на общедоступные методы, а также на все открытые свойства (я полагаю, общедоступные методы получения / установки в Java). Если бы мне пришлось вытаскивать число из воздуха, когда оно могло бы привлечь мое внимание, я бы сказал, когда их больше 10. Действительно, если в нем более 5 свойств или методов, я посмотрю и часто найду способы рефакторинга, но все, что больше 10, обычно является предупреждением о том, что что-то, скорее всего, будет плохо экспонировано.

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

Попробуйте использовать лучший показатель.

Одним из примеров является ABC Metric . Это скорее показатель того, сколько работы выполняется кодом, чем количество кода.

Любая строка, попадающая в проблемную область вашего класса, написанная вне класса, - это одна строка слишком мало и одна слишком много в классе, где она живет. Думайте о классе как о теме. Вы должны покрыть это. Идеально, как можно более кратко, идеально, но если он занимает 500 строк, он занимает 500 строк. Если 100 из этих строк охватывают другую тему, они принадлежат где-то еще. Разбивка на более мелкие субдомены внутри класса как внутренних классов имеет смысл, но я бы определил те, которые находятся вне класса, если бы они использовались где-то еще.