Накладные расходы большого размера в С#

Довольно академический вопрос - я заметил, что класс, который я написал в службе WCF, очень длинный (~ 3000 строк), и его следует разбить на более мелкие классы.

Сфера действия службы со временем возрастает, а содержащиеся в ней методы содержат много похожих функций, поэтому я не создаю несколько меньших классов до сих пор, поэтому у меня нет проблем с этим (кроме времени, которое потребуется сделать так!), но это заставило меня задуматься - есть ли существенная накладная производительность при использовании одного большого класса вместо нескольких меньших классов? Если да, то почему?

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

  • Поддержание работоспособности... Трудно сделать точечные исправления во множестве кода.
  • Считываемость... Если вам нужно листать вверх и вниз, как дьявол, чтобы получить куда угодно, это не читаемо.
  • Повторяемость... Без разложения затрудняет повторное использование.
  • Сплоченность... Если вы тоже многие вещи в одном классе, это, вероятно, не сплоченно.
  • Testability... Удачи, тестируя 3 000 LoC-пакетов спагетти на любой разумный уровень охвата.

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

Обычно я нахожу, что если я реорганизую одну из этих 10k строк бегемотов кода, общая сумма строк кода новых классов составляет 40% от оригинала, если не меньше. Дополнительные классы и разложение (в пределах разумного) приводят к меньшему количеству кода. Сначала неинтуитивный, но он действительно работает.

Ответ 4

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

Этот материал непросто "получить". Если вы программируете на языке OO, пока вы смотрите на SOLID, и это внезапно имеет такой смысл. Но пока эти лампочки не появятся, может показаться немного неясным.

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

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

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

Ответ 5

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

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

Точно так же, как я уже много раз предупреждал о SO... Люди боятся преждевременной оптимизации, но они не боятся писать плохой код с идеей вроде "Я исправлю это позже, когда это становится проблемой". Позвольте мне рассказать вам кое-что - 3000+ LOC класс уже является проблемой, независимо от воздействия производительности, если таковые имеются.

Ответ 6

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

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

Но в этом случае подумайте не о производительности, подумайте об этом дизайне. Лучше подумать о поддержке и дальнейшей разработке и тестировании. Классы 3K LOC - огромные и типичные книги анти-моделей. Такие классы приводят к дублированию кода и ошибкам, дальнейшая разработка будет болезненной и вызывает появление исправленных ошибок снова и снова, код является хрупким.

Так что класс определенно должен быть реорганизован.