Классы С# в отдельных файлах?

Должен ли каждый класс моего проекта С# получить собственный файл (на ваш взгляд)?

ОТВЕТЫ

Ответ 1

В то время как один класс для политики файлов строго соблюдается на Java, он не требуется для С#. Однако, это вообще хорошая идея.

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

Однако вы можете разделить один класс на несколько файлов с помощью ключевого слова partial. Это полезно для разделения кода на код, созданный мастером.

Ответ 2

Файлы дешевы, вы никому не помогаете, объединяя много классов в отдельные файлы.

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

Ответ 3

Как говорили другие, один файл для каждого типа в целом - хотя, если другие сделали публичное/частное различие, я бы просто сказал "один файл верхнего уровня для каждого типа" (поэтому даже внутренние типы верхнего уровня получают свои собственные файлы).

У меня есть одно исключение из этого, что менее важно с появлением типов делегатов Func и Action в .NET 3.5: если я определяю несколько типов делегатов в проекте, я часто объединяю их в файл, называемый Delegates.cs.

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

public partial class MessageDescriptor : IDescriptor<MessageDescriptorProto> {}
public partial class FileDescriptor : IDescriptor<FileDescriptorProto> {}

и т.д.. Включение всех их в свои собственные файлы было бы немного глупым.

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

Ответ 4

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

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

Foo.cs://Содержит только реализацию Foo

public partial class Foo 
{
   // Foo implementation
}

Foo.Bar.cs://Содержит только реализацию Foo.Bar

public partial class Foo
{
  private class Bar
  {
    // Bar implementation
  }
}

Ответ 5

Это зависит. Большую часть времени я бы сказал "да", поместив их в отдельные файлы. Но если бы у меня был закрытый вспомогательный класс, который будет использоваться только одним другим классом (например, Linked List Node или Element), я бы не рекомендовал их разделять.

Ответ 6

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

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

Ответ 7

Публичные классы: да Частные классы: (само собой разумеется) нет

Ответ 8

Я действительно предпочитаю довольно большие файлы .cs, 5000 строк довольно разумные IMO, хотя большинство моих файлов на данный момент всего около 500-1000 (в С++, однако, у меня были некоторые страшные файлы), однако, "Просмотр обозревателя объектов/класс", "Перейти к определению" и "инкрементный поиск" (-I; Спасибо за этот совет, Джефф Этвуд!), Все упрощают поиск определенного класса или метода.

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

Это, конечно, сильно зависит от того, как вы работаете, но есть более чем достаточно инструментов, чтобы не нужно использовать ужасную старую навигацию на основе файлов на основе 70-х (Joking, если бы это было не очевидно).

Ответ 9

Как человек, который кодировал большие файлы в течение многих лет (ограничен 1000 строк), на самом деле, так как я начал программировать в детстве, я был удивлен огромным консенсусом в этом правиле "один класс за исходный файл".

"Один класс для исходного файла" не без проблем. Если вы работаете над множеством вещей одновременно, у вас будет много файлов. Конечно, вы могли бы закрыть файлы, как только закончите с ними, но что, если вам нужно их повторно открыть? Обычно при каждом открытии файла обычно происходит задержка.

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

  • "Мне не нравится прокручивать вверх и вниз" - Bad Reason - современные IDE теперь либо имеют встроенные функции для быстрого доступа к нужному вам коду, либо вы можете установить расширения/плагины для этой задачи. Visual Studio Solution Explorer делает это со своей функцией поиска, но если этого недостаточно, купите VisualAssist. VisualAssist предоставляет контуры элементов в исходном файле. Не нужно прокручивать, но дважды нажмите на то, что вы хотите.

Существует также сворачивание кода. Слишком много кода? Просто сверните его в одну строку! Проблема решена.

  1. "Вещи легче найти, потому что они идентифицированы по файлу" - Bad Reason. Опять же, современные IDE упрощают поиск того, что вы ищете. Просто используйте Solution Explorer или купите VisualAssist! Технология там, используйте ее!

  2. "Легче читать/слишком много кода" - Плохой разум - я не слепой. Я вижу. Опять же, с кодовым сгибанием я могу легко устранить беспорядок и свернуть код, который мне не нужно видеть. Это не каменный век программирования.

  3. "Вы забудете, где классы находятся в больших проектах" - "Плохой разум" - простое решение: обозреватель решений в Visual Studio и расширение VisualAssist.

  4. "Вы знаете, что в проекте, не открывая ничего" - "Хороший разум" - нет споров с этим.

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

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

Ответ 10

Конечно! Почему бы и нет? Помимо частных классов глупо иметь несколько классов в одном файле.

Ответ 11

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

В дни распечатываемых списков исходного кода, работающих на многие сотни страниц (подумайте о телефонной книге), "правило трех пальцев" было хорошим рабочим пределом сложности: если вам понадобилось больше трех пальцев (или скрепки для бумаг) или post-its) в качестве заполнителей для понимания модуля, этот набор зависимостей модуля был, вероятно, слишком сложным. Учитывая, что почти никто не использует распечатки списков исходного кода, я предлагаю, чтобы это было обновлено как "правило трех окон" - если вам нужно открыть более трех дополнительных окон, чтобы понять код, отображаемый в другом окне, этот код, вероятно, должен быть реорганизован.

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