Плохая практика - иметь несколько классов в одном файле?

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

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

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

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

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

Это может быть плохо с точки зрения будущего развития и ремонтопригодности. Намного легче запомнить, где находится класс Car, если у вас есть класс Car.cs. Где искать класс Widget, если Widget.cs не существует? Это автомобильный виджет? Это виджет двигателя? Ой, может быть, это виджет рогалика.

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

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

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

Если удобно поместить их в один файл, будь моим гостем. Не могу сделать это с общедоступными классами в java;)

Как правило, лучше всего использовать один класс / один файл. Однако я часто храню несколько определений интерфейсов в одном файле. Несколько классов в одном файле? Только если они каким-то образом связаны с очень и очень маленькие (<5 методов и членов)

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

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

В Java один класс общественный на файл - это способ работы языка. Группа файлов Java может быть собрана в пакет.

Однако в Python файлы являются «модулями» и обычно имеют ряд тесно связанных классов. Пакет Python - это каталог, как и пакет Java.

Это дает Python дополнительный уровень группировки между классом и пакетом.

Не существует единственного верного ответа, не зависящего от языка. Это зависит от языка.

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

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

public class Customer { /* whatever */ }

public class CustomerCollection : List<Customer> { /* whatever */ }

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

Как и в большинстве случаев в программировании, это во многом зависит от ситуации.

Например, какова сплоченность рассматриваемых классов? Они сильно связаны? Они полностью ортогональны? Связаны ли они по функциональности?

Для веб-фреймворка было бы нормальным предоставлять виджеты общего назначения, какой бы файл ни содержал BaseWidget, TextWidget, CharWidget и т. д.

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

Когда классы ортогональны и не имеют ничего общего друг с другом, группировка в один файл действительно будет искусственной. Предположим, приложение управляет роботизированной фабрикой, производящей автомобили. Файл с именем parts, содержащий CarParts и RobotParts, был бы бессмысленным ... вряд ли существует большая связь между заказом запасных частей для обслуживания и деталями, которые производит завод. Такое объединение не добавит никакой информации или знаний о разрабатываемой вами системе.

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

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

Ответ Smalltalk: у вас не должно быть файлов (для программирования). Они затрудняют управление версиями и навигацию.

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

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

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

Поскольку ваш IDE предоставляет вам функциональность «Перейдите к», и у вас есть некоторый контроль над пространство имен в ваших классах, то приведенные ниже преимущества наличия нескольких классов в одном файле для меня вполне того стоят.

Родительские - Дочерние классы

Во многих случаях я считаю весьма полезным иметь классы Унаследовано в их файле классов Основание.

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

Public: Small - Helper - DTO Classes

Когда вам нужно несколько классов простой и маленький для специфическая функциональность, я считаю совершенно излишним иметь файл со всеми ссылками и включать только класс 4-8 лайнер .....

Кодовая навигация также проще, просто прокручивая один файл вместо переключения между 10 файлами ... Также проще рефакторинг, когда вам нужно отредактировать только одну ссылку вместо 10 ...

Общее нарушение Железное правило 1 класс на файл дает дополнительный Свобода для организации вашего кода.

Что произойдет дальше, на самом деле зависит от вашей IDE, языка, навыков командного общения и организационных навыков.

Но если вы хотите эту свободу, зачем жертвовать ею ради железного правила?