Один класс на файловое правило в .NET?

Question

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

Другой аргумент, который я слышу все время: «Даже Microsoft не делает этого, так почему мы должны?»

Какой общий консенсус по этому поводу? Есть ли случаи, когда этого следует избегать?

Answer 1

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

1. Делает код легче усваивается и поддерживать
2. делает решение менее раздражающим (прокручивая бесчисленное множество ненужные файлы) и менее медленно
3. Команда разработчиков в порядке с это как местная практика кодирования

Действительно хороший пример того, почему мне может понадобиться несколько классов на файл:

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

Answer 2

Один класс на файл также дает вам лучшее представление о том, что меняется при каждой регистрации, не глядя на различия в файле.

Answer 3

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Answer 4

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

Общая «лучшая практика» - иметь по одному файлу на класс.

Answer 5

Помимо гипотетических аргументов и сосредоточения вместо этого на Windows .NET с Visual Studio IDE и растущими программными проектами, в этом контексте имеет смысл иметь только один класс на файл.

---

В общем, для визуальной ссылки ничто не сравнится с одним классом на файл. На самом деле.

Я не знаю, делает ли Microsoft то же самое или нет, однако они создали ключевое слово partial , чтобы разделить один класс на несколько файлов (это еще тяжелее). Он часто используется для отделения автоматически сгенерированного кода конструктора от вашего пользовательского кода в того же класса (но иногда используется, чтобы позволить различным разработчикам одновременно работать над классом через разные файлы). Таким образом, Microsoft видит преимущества использования нескольких файлов, и каждый наверняка задумывается о нескольких организациях файлов .NET.

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

class BicycleWheel {
    class WheelSpoke {
    }
}

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

Кроме того, если вы используете папки для пространств имен , то у вас никогда не будет конфликта имен файлов классов. Также удобно найти класс по имени файла в файловой системе , когда он не находится в среде разработки, такой как Visual Studio (например, , если вы хотите быстро редактировать класс с помощью Блокнота или чего-то быстрого / легкого ).

Так много веских причин ...

Answer 6

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

Answer 7

Я тоже считаю, что в один файл должен быть включен один тип.

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

RelayCommand     

и

RelayCommand<T>

Answer 8

Независимо от того, насколько легок контент, я думаю, что один класс / интерфейс / и т. Д. На файл необходим.

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

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

Answer 9

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

Также для людей, которые не могут найти определенные классы, если они не все находятся в файлах, названных так, как они есть, есть ли причина, по которой вы не пользуетесь поиском, просматривая все решение? Использование Find экономит мое драгоценное время при просмотре Solution Explorer.

Answer 10

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