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

Question

Раньше у меня был один класс для одного файла. Например, car.cs имеет класс car . Но так как я программирую больше классов, я хотел бы добавить их в тот же файл. Например, car.cs имеет класс автомобиль , класс дверь и т. Д.

Мой вопрос хорош для Java, C #, PHP или любого другого языка программирования. Должен ли я попытаться не иметь несколько классов в одном файле, или это нормально?

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

public class Customer { /* whatever */ }

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

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

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

Public: Small - Helper - DTO Classes

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

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

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

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

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