2013-05-03 6 views
0

a писали веб-приложение Java EE 6, которое действительно мое первое серьезное приложение. Я кодирую. Я отметил, что мои классы составляют 500 строк до 1000 и, вероятно, могут увеличиться. Я понятия не имею, насколько большой класс должен быть, или если это имеет значение, но я не хочу продолжать писать гигантские классы, если это повлияет на производительность приложений отрицательно. какой совет у вас есть для меня?Каков рекомендуемый размер класса?

+1

Размер не может повлиять на производительность, но, безусловно, сделать это трудно поддерживать код. –

+3

Если ваши классы 500-1000 строк, то они слишком большие. Не с точки зрения производительности, а с точки зрения качества кода. Держите свои классы маленькими и точными. Они должны нести одну ответственность. – NilsH

+1

@NilsH - С другой стороны, * некоторые * классы не могут быть короткими и точными из-за того, что они должны делать. Если вы попытаетесь реорганизовать их, они не смогут этого сделать. По общему признанию, такие классы необычны ... –

ответ

1

«Первое правило классов состоит в том, что они должны быть небольшими. Второе правило классов состоит в том, что они должны быть меньше этого».

Название класса должно описывать, какие обязанности он выполняет. Фактически, имя , вероятно, является первым способом помочь определить размер класса. Если мы не сможем получить краткое имя для класса, то оно, вероятно, слишком велико. Чем более неоднозначно название класса, тем больше вероятность, что у него слишком много обязанностей. Например, имена классов, включая слова ласки , такие как Процессор или Менеджер или Супер, часто намекают на неудачную агрегацию обязанностей .

Мы также должны быть в состоянии написать краткое описание класса в около 25 слов, без использования слова «если» «и», «или» или «но». Как бы мы описываем SuperDashboard? «SuperDashboard предоставляет доступ к компоненту, который в последний раз удерживал фокус , а также позволяет отслеживать версии и строить номера». Первый «и» - это намек на то, что SuperDashboard имеет слишком много обязанностей.

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

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

-из Чистый код: Справочник по Agile Software Мастерства

+0

Спасибо вам большое. Ваш ответ очень исчерпывающий и представил мне новые концепции, о которых я не знал. Думаю, мне нужно реорганизовать и посмотреть, что нужно переместить, где – qualebs

1

Вообще говоря, я бы придерживался, насколько это возможно, метода, не превышающего одну страницу. Так скажите, что один метод - 50 строк + комментарии, большой метод BTW, так что это означало бы, что у вас было бы 6 методов в 500 строк. Я подозреваю, что у вас есть методы, превышающие страницу, что делает ваши классы очень большими.

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

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

1

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

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

Кроме того, существуют ограничения на JVM, о которых вам нужно знать, например размер метода, как описано in this article.

Вам следует удалить методы, которые вам больше не нужны (или которые, возможно, были добавлены только из страха). Если код не используется, он имеет значение меньше нуля. Класс должен иметь одну и только одну четко определенную ответственность. Если ваш класс имеет/имеет/делает несколько разных вещей, что вы собираетесь назвать классом?

Необходимо найти правильный баланс.

Смежные вопросы