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

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

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

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

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

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

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

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

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

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

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

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

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

class BicycleWheel {
    class WheelSpoke {
    }
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

т.е.

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

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

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

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

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

Один случай может быть таким: когда ваши классы совместно образуют модуль / модуль , который обслуживает некоторые основные классы , такие как вспомогательные классы , в противном случае ] № .

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

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

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

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

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

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

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

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

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

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

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

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

Как только вы начнете правильно разрабатывать программное обеспечение (IoC, паттерны проектирования, DDD, TDD и т.д...) и покинете игровую площадку "омг, давайте сделаем это, я понятия не имею как, но мне заплатят", вы увидите, что это правило действительно, действительно, имеет значение.