В С# сколько строк перед классом следует рассматривать как рефакторинг?

Хорошим правилом является то, что я разумно реорганизую любой метод на 50 строк.

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

У меня нет правила для классов. Обычно я не проверяю классы, чтобы проверить, нужно ли их рефакторировать.

В моем проекте в настоящее время у меня всего лишь класс, длина которого составляет почти 4000 строк. Однако никакие методы более 50, и большинство линий и методов не являются частными и не действуют ни на какие данные вне класса.

Какое правило для рефакторинговых классов?

Ответ 1

Когда класс нарушает SRP, это время для рефакторинга.

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

Ответ 2

Если ваши классы нарушили одно из следующих "правил", вам следует подумать о рефакторинге.

Вы ищете SOLID, более подробные скринкасты можно найти здесь.

S RP: принцип единой ответственности, никогда не должно быть более одной причины для изменения класса.
O CP: открытый закрытый принцип, программные объекты (классы, модули, функции и т.д.) Должны быть открыты для расширения, но закрыты для модификации.
L SP: принцип подстановки Лискова, функции, использующие ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом.
I SP: принцип сегрегации интерфейса, клиенты не должны зависеть от интерфейсов, которые они не используют.
D IP: принцип инверсии зависимости:
- модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций.
- абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Ответ 3

Не позволяйте LOC быть вашей основной метрикой. Мне кажется, 50 строк кажутся мне очень маленькими. С 50 файлами линии вы получите недружественное количество файлов классов в решении. Ваша производительность будет ослаблена всей навигацией, которую вы будете делать между файлами, и ваша среда IDE всегда будет завалена слишком большим количеством вкладок. Я лично стараюсь сначала организовать классы в логические группы по пространству имен. В классе по классам я стараюсь сделать код более легким и понятным для чтения. Иногда файлы классов становятся большими. Я начинаю испытывать больное чувство, когда файл класса - это 2000+ строк. Что-то меньшее, чем это, я имею дело в каждом отдельном случае.

Ответ 4

Я бы не сказал, что существует какое-либо "эмпирическое правило" для рефакторинга больших классов. Иногда класс действительно инкапсулирует много бизнес-логики и должен быть таким большим, как есть. Однако вы можете задать себе несколько вопросов:

(Предполагая, что вы пишете объектно-ориентированный код) Является ли мой код действительно объектно-ориентированным? То есть, соблюдает ли он принцип единой ответственности (спасибо, Небаканезер)? Является ли этот класс вспомогательным классом? Если да, как я мог бы реорганизовать свои методы на более подходящие классы объектов?
Есть ли у меня прочная архитектура? То есть я использую абстракцию и наследование вместо того, чтобы повторно изобретать колесо в каждом классе? Перегружены ли методы, вызывающие базовые методы по мере необходимости?
Мне действительно нужен весь этот код? Может ли какая-то логика быть экстернализована с использованием xpath, лямбда-выражений или какой-либо формы выражений, управляемых базой данных?
Является ли код расширяемым? Легко ли поддерживать? Было ли это хорошо продуманным с самого начала, или мы всегда делаем небольшие исправления, чтобы попытаться исправить проблемы?

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

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

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

Ответ 5

В С# мое эмпирическое правило для классов - это нечто большее, чем 500 строк, слишком длинное. Мне очень нравятся методы под 10 строками, и я думаю, что до 20 приемлемо. Я думаю, что это действительно зависит от контекста.

Ответ 6

Рефакторинг всякий раз, когда у вас есть возможность:

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

и т.д. и т.д.

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

Ответ 7

Рефакторинг - это не столько сокращение количества LOC, хотя это побочный эффект, но и улучшение качества. В частности, вы хотите попытаться следовать принципу DRY (Do not Repeat Yourself) насколько это возможно, разумно.

Ответ 8

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

Ответ 9

Я склонен смотреть на циклическую сложность каждого члена вместо количества строк кода для всего класса.

Ответ 10

Этот класс может быть кандидатом на рефакторинг "извлечение объекта, который, как вы думаете, не существует"?

Возможно, например, вы можете извлечь объект метода, который позволит вам реорганизовать несколько из 50 методов линии в члены выделенного класса?

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

Одной строки достаточно, чтобы рассмотреть рефакторинг. 40 каждый 50-строчный метод начинает кричать "Я слишком сложен, там другой объект скрывается здесь" к моему уху.