2010-09-23 2 views
7

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

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

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

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

Также: C# имеет ключевое слово partial, которое позволяет разбить класс на любое количество файлов, не затрагивая функциональность. Тем не менее, я заметил, что Microsoft, похоже, использует partial, чтобы скрыть сгенерированный код от вас (Winforms/WPF.), Что заставляет меня задаться вопросом, является ли разделение класса просто потому, что оно имеет много строк, является законным использованием partial - не так ли?

Спасибо

+3

Если вы можете разбить класс на несколько 'partial' файлов, которые логически разделены, perhpas, вы должны разбить класс до нескольких классов. У вас может быть слишком большая ответственность в одном месте. – Oded

+2

Используйте только частичные для частично генерируемых классов. –

ответ

13

Отделите свой код на обязанности. Для каждой ответственности определите один тип. То есть, следуйте Single Responsibility Principal. Это приведет к меньшим единицам кода, каждый из которых выполняет очень специфическую функцию. Это не только приводит к уменьшению файлов, но и к лучшему дизайну и удобству обслуживания.

+0

Как это применимо к классу кода WPF? – Gabe

+0

@Gabe: Большинство (часто все) функциональности для представления находятся в одной или нескольких моделях просмотра. Вслед за SRP подразумевается, что каждая VM несет отдельную ответственность, вместо того, чтобы сбрасывать все, что связано с представлением, в одну виртуальную машину. Тем не менее, иногда бывает хорошо иметь код в коде, если он строго просматривает связанную (а не бизнес-логику) и не разделяется другими представлениями (а не общим компонентом или поведением). В этом случае SRP все еще остается в силе, потому что ответственность заключается в том, чтобы «проявить точку зрения», так сказать. –

2

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

Насколько я понимаю, частичное означает, что класс существует в двух отдельных файлах. Веб-формы и элементы управления являются частичными, потому что другая «часть» файла представляет собой файл [p | c] x, который идет с ним.

+3

Регионы: просто скажите нет;) –

+0

@ Kent - они не так уж плохи. Они только сжигали мой дом один раз. – Oded

+3

Использование регионов в файлах классов часто является признаком плохого OOD ... И никогда не скрывайте сложность! Сделать его менее сложным ;-) –

9

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

1

Я исхожу из того, что если вы не можете увидеть весь метод на одном экране (т. Е. Вам нужно прокрутить), вы должны разбить метод на дополнительные методы - либо в том же классе, либо когда код будет использоваться более одного раза в класс помощников.

5

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

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

0

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

0

Для улучшения считывания кода: вы можете использовать региональный блок: https://msdn.microsoft.com/en-us/library/9a1ybwek.aspx. Что касается улучшения структуры и дизайна вашего кода - обратитесь к некоторым специализированным книгам.

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

  • Нет связанных вопросов^_^