Один класс на файловое правило в .NET? [закрыто]

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

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

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

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

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

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

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

Скажем, у меня есть несколько десятков пользовательских классов исключений, каждый из которых имеет 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 (например, если вы хотите быстро отредактировать класс с помощью Блокнота или чего-то быстрого / легкого ).

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

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

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

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

RelayCommand     

и

RelayCommand<T>

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

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

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

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

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

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

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

Итак, дело в том, что следует использовать усмотрение !!!

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

Инструмент StyleCop для C # имеет стандартные правила, которые требуют не более одного класса верхнего уровня в одном пространстве имен (плюс любое количество интерфейсов, делегатов и перечислений в этом пространстве имен).

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

Иногда один класс на файл, но ...

Когда несколько классов строго связаны, более одного класса в одном и том же исходном файле, ИМХО, ЛУЧШЕ, чем выделение короткого исходного файла для каждого класса. Источник более читабелен и компактен (и с помощью #region тот же источник может быть более структурированным, чем раньше).

Учтите также, что иногда НЕОБХОДИМО распространять один и тот же класс по разным файлам (используя частичные ), поскольку наличие исходного файла с строкой 20000+ не удобно даже с имеющейся у меня оперативной памятью (но это другой вопрос).

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

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

то есть.

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

Это действительно проблема? :)
Действительно маленькие классы, как и перечисления, могут быть объединены с другими. Есть одно правило: соберите вместе только те классы, которые имеют что-то общее.

Как отступление - в одном из моих проектов у меня есть файл, который содержит 150 классов внутри. Файл имеет 10000 строк кода. Но это автоматически генерируется, так что это вполне приемлемо :)

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

Я делаю это, но только тогда, когда классы связаны по типу дочерний-родитель, а дочерние классы используются ТОЛЬКО родителем.

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

• EventArgs.cs, который содержит любые EventArgsподклассы, так как они обычно содержат всего 5-10 строк кода, но обычно они используются несколькими различными классами. В качестве альтернативы я мог бы поместить EventArgsклассы в тот же файл, что и класс, который объявляет события.
• Delegates.cs, который содержит делегаты, которые используются в проекте, так как обычно они содержат только одну строку. Опять же, альтернатива состоит в том, чтобы поместить их в один файл с классом, который выставляет / потребляет их.
• Enums.cs, содержащий файлы, enumиспользуемые в проекте. (Если есть, enumкоторый используется только одним классом, я обычно делаю это privateк этому классу.)

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

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

До сих пор ответы, похоже, вращались вокруг исключений людей из правила, поэтому вот мое: я держу вместе классы и их «меткие» классы метаданных при использовании пакета DataAnnotations в .NET3.5 SP1. В противном случае они всегда в отдельных файлах. Вы знаете, большую часть времени. За исключением случаев, когда они не.

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

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

One case could be:когда ваши классы совместно образуют, module / unitчто служит некоторым основным классам, как helper classes, другим мудрым нет .

взгляните на исходный код проекта ASP.NET MVC 2.0 . Строго следует этому правилу

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

Я не стал бы следовать практикам РС, поскольку они не ЛУЧШИЕ ПРАКТИКИ!

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

Например: у вас может быть два класса, где один класс использует Linq, а другой нет.

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

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

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

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

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

Один класс на файл - это однозначное правило, не подлежащее интерпретации.

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

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

Мне любопытно, зависит ли какой-либо из ваших ответов от того, являетесь ли вы: (1) разработкой приложения для Windows Forms, веб-приложения, библиотеки или чего-либо еще; или (2) с использованием Visual Studio или нет. При использовании VS может показаться, что один класс на правило файла будет также подразумевать один класс на проект VS, поскольку в других потоках предполагается, что решения / проекты VS должны отражаться в именах и структуре каталогов / файлов. Действительно, у меня сложилось впечатление, что концепция должна иметь имя проекта = имя сборки = (вложенное) имя пространства имен, которое затем будет отражено в именах и структуре каталогов / файлов. Если это правильные руководящие принципы (или правила), то все эти, казалось бы, ортогональные организационные механизмы, тем не менее, будут синхронизированы.

Да, для удобства чтения у нас должен быть один файл на класс! Просто запрыгнул в проект. Я вижу много классов в одном файле. новому парню так трудно это понять. мы не должны думать о ремонтопригодности? когда мы разрабатываем программное обеспечение? Много раз разработка будет продолжена другими разработчиками. У нас есть пространства имен, чтобы упорядочить наши вещи, нам не нужны файлы для этого!

Один элемент кода на файл, да.

Все остальное - злоупотребление служебным положением - и, откровенно говоря, признак жертвы RAD.

Как только кто-то начинает правильную разработку программного обеспечения (IoC, шаблоны проектирования, DDD, TDD и т. Д.) И оставляет «Боже мой, давайте сделаем это», я понятия не имею, как, но мне платят », можно увидеть, что это правило действительно, действительно, имеет значение.