Я следую этому правилу, но некоторые из моих коллег не согласны с ним и утверждают, что если класс меньше, его можно оставить в том же файле с другим классом (es).
Еще один аргумент, который я все время слышу: "Даже Microsoft этого не делает, так почему мы должны?"
Какое общее мнение по этому поводу? Есть ли случаи, когда этого следует избегать?
Один класс для каждого файла также дает вам представление о том, что меняется каждый чек, не глядя на разницу между файлами.
Я ненавижу это, когда люди думают в абсолютах и говорят, что вы никогда не должны делать то или это с чем-то субъективным и ничтожным, как будто это все, что нам нужно, чтобы соответствовать каким-то глупым представлениям о правильном и неправильном. Нижняя строка: наличие более одного класса для каждого файла совершенно нормально, если это имеет смысл.. Имеет смысл, я имею в виду такие вещи, как:
Действительно хороший пример того, почему я могу использовать несколько классов для каждого файла:
Скажем, у меня есть несколько десятков настраиваемых классов исключений, каждый из которых представляет собой 4 лайнера, у меня может быть отдельный файл для каждого из них, или я мог бы группировать исключения и иметь файл для каждой группы. Для меня самый рациональный/прагматичный подход состоит в том, чтобы сгруппировать их и просто иметь несколько файлов, потому что это более эффективное время/кодирование (я не должен щелкнуть правой кнопкой мыши → Добавить класс, переименовать, 50 раз), он сохраняет решение менее загроможденным и более эффективным.
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
return (rule.Overhead(useCase)
< My.PersonalThresholds.ConformismVsPracticality);
}
Я иногда группирую более одного класса в файле, если они плотно связаны и по крайней мере один из них очень мал.
Общая "лучшая практика" - иметь один файл для каждого класса.
Помимо гипотетических аргументов и вместо того, чтобы сосредоточиться на Windows.NET с Visual Studio IDE и растущих программных проектах, в этом контексте имеет смысл иметь один класс для каждого файла.
В общем случае для визуальной ссылки ничто не сравнится с одним классом в файле. На самом деле.
Я не знаю, делает ли Microsoft или не делает то же самое, однако они создали partial ключевое слово для разделения один класс над несколькими файлами (это еще более серьезный). Он часто использовался для разделения кода сгенерированного автоматически кода разработчика из вашего настраиваемого кода в том же классе (но иногда он используется, чтобы позволить различным разработчикам работать над классом одновременно с помощью разных файлов). Таким образом, Microsoft видит преимущества нескольких файлов, и у всех есть несколько идей для организации файлов в уме с .NET.
Для вложенных классов у вас нет выбора, кроме как использовать один файл или, по крайней мере, первые части классов в них. В этом случае необходим один файл и в этом случае:
class BicycleWheel {
class WheelSpoke {
}
}
В противном случае, почему бы вам сохранить несколько классов в одном файле? Аргумент "потому что они маленькие" или связаны друг с другом не содержит много воды, потому что в конечном итоге ваши классы будут связаны с другими классами. В конечном счете вы не можете легко заключить внутрикорпоративную организацию объектов на основе их использования, особенно по мере того, как программное обеспечение продолжает расти.
Кроме того, если вы используете папки для пространств имен, у вас никогда не будет столкновения имени файла класса. Также удобно находить класс по имени файла в файловой системе, если не внутри среды разработки, такой как Visual Studio (например, , если вы хотите быстро отредактировать класс с помощью Notepad или чего-то быстрого/легкого).
Так много веских причин...
В подавляющем большинстве случаев я следую одному классу за правило файла. Единственное исключение, которое я регулярно делаю, - это определение перечисления, которое тесно связано с определенным классом. В этом случае я часто включаю определение перечисления в файл этого класса.
Я тоже считаю, что в одном файле должен быть один тип.
Есть одно исключение из этого правила, которое должно быть упомянуто: наличие двух классов, которые отличаются только общим аргументом, таким как:
RelayCommand
и
RelayCommand<T>
В более крупных решениях я считаю, что очень полезно иметь один класс для каждого файла и что файл называется тем же, что и класс. Это значительно упрощает поиск кода, в котором вы должны работать.
Средство StyleCop для С# имеет стандартные правила, которые требуют не более одного класса верхнего уровня в одном пространстве имен (плюс любое количество интерфейсов, делегатов и перечислений в этом пространстве имен).
В случае двух или более классов, где второй и последующие классы используются только первым, они могут и должны быть внутренними классами, видимыми только для класса-потребителя.
Действительно, это сводится к личным предпочтениям. Все скажут "один класс за файл", но у всех нас есть причины избежать этого при определенных обстоятельствах. Раньше у меня был большой проект, в котором было около 300 различных перечислений. Ни в коем случае я не буду иметь 300 отдельных файлов, по одному для каждого класса, когда некоторые из перечислений только были три-состояния.
Также для людей, которые не могут найти определенные классы, если они не все в файлах, названных в честь того, что они есть, есть ли причина, по которой вы не используете Find look in whole solution? Использование Find экономит время для прокрутки в обозревателе решений.
Я считаю, что группировка класса со стандартным классом factory в том же файле очень полезна.
Независимо от того, насколько легкий контент, я думаю, что один класс/интерфейс/т.д. для каждого файла имеет важное значение.
Если я работаю над большим решением в Visual Studio, я хочу видеть файлы и не просматривать их внутри. Даже с инструментами навигации, такими как ReSharper, я хочу отобразить 1:1.
Если вы найдете много исходных файлов с небольшим или отсутствующим контентом (возможно, расширение класса, но ничего не добавляющее к нему), то, возможно, вам следует переосмыслить свой дизайн.
Обычно я должен иметь один класс для каждого файла, но обычно вы должны использовать свое усмотрение, чтобы увидеть, может ли файл содержать связанные классы, например. группируя ваши исключения, которые могут быть повторно использованы самим и другими разработчиками. В этом случае пользователю нужен только один файл для включения, а не несколько файлов.
Итак, дело в том, что дискретность должна использоваться!!!
Когда-то один класс для файла, , но...
Когда несколько классов связаны строго, более одного класса в одном исходном файле, IMHO, ЛУЧШЕ, чем выделение короткого исходного файла для каждого класса. Источник является более читаемым и компактным (и используя #region, тот же источник может быть более структурированным, чем раньше).
Считайте также, что иногда он НЕОБХОДИМО распространять один и тот же класс в разных файлах (с использованием частичного), так как наличие исходного файла с 20000+ не является удобным даже в том, что у меня есть RAM (но это это еще один вопрос).
Это действительно проблема?:)
Действительно маленькие классы, как и перечисления, могут быть объединены с другими. Там должно быть одно правило: собрать только классы, которые имеют что-то общее.
Как отступление - в одном из моих проектов у меня есть файл, в котором есть 150 классов. Файл имеет 10000 строк кода. Но он автоматически генерируется, поэтому он полностью приемлем:)
Иногда я оставляю небольшой класс с большим классом, но только если они очень тесно связаны как с объектом, так и с его классом коллекции или factory.
Есть одна проблема с этим. В конце концов маленький класс растет до такой степени, что он должен быть в собственном файле, если вы переместите его в новый файл, вы потеряете легкий доступ к своей истории изменений.
т.
Одна из причин размещения нескольких классов в одном файле заключается в том, что бедный ублюдок, который использует ваш API, не должен тратить полдня на печать шаблона импортной декларации и бедный ублюдок, который должен для поддержания кода не нужно тратить полдня на прокрутку шаблона импортной декларации. Мое эмпирическое правило состоит в том, что несколько классов принадлежат одному файлу, если вы почти всегда используете большой подмножество из них одновременно, а не только по одному.
Я делаю это, но только тогда, когда классы связаны с дочерним родителем, а дочерние классы ТОЛЬКО используются родителем.
Я делаю это редко. Например, если есть перечисление или структура, которые тесно связаны с классом, но слишком тривиальны для самостоятельного разделения.
Или отдельный класс, содержащий некоторые методы расширения для этого основного класса.
До сих пор ответы, похоже, вращаются вокруг исключений людей в правиле, поэтому здесь мои: я сохраняю классы и их группы "приятелей" метаданных вместе при использовании пакета DataAnnotations в .NET3.5 SP1. В противном случае они всегда находятся в отдельных файлах. Знаете, большую часть времени. За исключением случаев, когда это не так.
Еще одно голосование за один класс за файл с именем файла так же, как класс. Для меня это помогает с долговременной ремонтопригодностью. Я могу легко просмотреть репозиторий и посмотреть, какие классы являются частью решения, не открывая проект или какие-либо файлы.
Я следую ему в 99% случаев. Хорошо следовать стандартам, но я также считаю, что гибкость имеет свое место. Иногда кажется, что это просто глупая трата времени, чтобы разбить вещи. В те времена я сам перебираюсь и просто пишу свой код.
One case could be:, когда ваши классы совместно образуют module / unit, который обслуживает некоторые основные классы
например helper classes, другой мудрый нет.
посмотрите ASP.NET MVC 2.0. Это строго следует этому правилу
Мне нравится идея создания меньших классов и убедитесь, что класс делает только то, что он должен делать. Если у вас есть несколько классов, которые способствуют решению одной проблемы, тогда нет никакого вреда в их объединении в один и тот же файл.
Я не буду следовать методам MS, поскольку они не являются ЛУЧШЕЙ ПРАКТИКОЙ!
Обычно я использую один класс для каждого файла. Но я сделаю исключения для групп похожих конструкций, которые используются по всему проекту. Например:
EventArgs, поскольку они обычно всего 5-10 строк кода, но обычно они используются несколькими разными классами. В качестве альтернативы я мог бы поместить классы EventArgs в тот же файл, что и класс, объявляющий события.enum, используемый во всем проекте. (Если есть enum, который используется только одним классом, я обычно делаю его private для этого класса.)Взад и вперед было очень интересно и, казалось бы, неубедительно, хотя мое общее впечатление состоит в том, что сопоставление 1-1 между классами и файлами является мнением большинства, хотя и с некоторыми индивидуальными исключениями.
Мне интересно, если любой из ваших ответов зависит от того, являетесь ли вы: (1) разработкой приложения Windows Forms, веб-приложения, библиотеки или чего-то еще; или (2) с помощью Visual Studio или нет. При использовании VS было бы очевидно, что одно класс для каждого правила файла также будет подразумевать один класс для VS-проекта, поскольку консенсус в других потоках, по-видимому, заключается в том, что VS-решения/проекты должны быть зеркалированы в именах и структуре каталога/файла. В самом деле, мое впечатление состоит в том, что в консенсусе должно быть имя имени проекта = имя сборки = (вложенное), все из которых затем будут отражены в именах и структуре каталога/файла. Если это правильные рекомендации (или правила), тогда все эти, казалось бы, ортогональные механизмы организации будут, тем не менее, синхронизированы.
Да для удобства чтения у нас должен быть один файл на класс!. Просто вскочил в проект. Я вижу много классов в одном файле. это просто делает так тяжело для нового парня, чтобы понять это. разве мы не думаем о поддержке? когда мы разрабатываем программное обеспечение? много раз развитие будет продолжаться другими разработчиками. У нас есть пространства имен, чтобы упорядочить наши вещи, нам не нужны файлы для этого!
Один элемент кода для файла, да.
Все остальное - злоупотребление служебным положением - и, откровенно говоря, признак жертвы RAD.
Как только вы запускаете правильную разработку программного обеспечения (IoC, шаблоны проектирования, DDD, TDD и т.д.) и оставляете "omg позволяет сделать это, я понятия не имею, как, но мне платят" игровая площадка, одна увидит, что это правило действительно, действительно имеет значение.