У меня был один класс для одного файла. Например, car.cs имеет класс автомобиль. Но поскольку я программирую больше классов, я хотел бы добавить их в один и тот же файл. Например car.cs имеет класс автомобиля и двери класса и т.д.Является ли плохой практикой иметь несколько классов в одном файле?
Мой вопрос хорош для Java, C#, PHP или любого другого языка программирования. Должен ли я попытаться не иметь несколько классов в одном файле или все в порядке?
Я думаю, вы должны попытаться сохранить свой код в 1 класс за файл.
Я предлагаю это, потому что вам будет легче найти ваш класс позже. Кроме того, он будет работать лучше с вашей системой управления версиями (если файл изменится, то вы знаете, что определенный класс изменился).
Единственный раз, когда я считаю правильным использовать более одного класса для каждого файла, это когда вы используете внутренние классы ... но внутренние классы находятся внутри другого класса и поэтому могут быть оставлены внутри одного и того же файла. Роли внутренних классов сильно связаны с внешними классами, поэтому размещение их в одном файле отлично.
Я обнаружил, что всякий раз, когда я пытаюсь объединить несколько типов в один файл, я всегда возвращаюсь назад и отделяю их просто потому, что он облегчает их поиск. Всякий раз, когда я совмещаю, всегда есть момент, когда я пытаюсь вычислить wtf, я определил тип x.
Итак, мое личное правило заключается в том, что каждый отдельный тип (за исключением, может быть, для дочерних классов, по которому средний класс внутри класса, а не унаследованный класс) получает свой собственный файл.
Это может быть плохо с точки зрения будущей разработки и ремонтопригодности. Гораздо легче запомнить, где класс Car, если у вас есть класс Car.cs. Где бы вы искали класс Widget, если Widget.cs не существует? Это автомобильный виджет? Это виджет двигателя? О, может быть, это виджет бублика.
Если вы работаете в команде, сохранение классов в отдельных файлах упрощает управление источником и уменьшает вероятность конфликтов (несколько разработчиков одновременно меняют один и тот же файл). Я думаю, что это облегчает поиск кода, который вы ищете.
только время Я рассматриваю расположение файлов, когда мне нужно создавать новые классы. В противном случае I никогда ориентироваться по структуре файла. Я использую «перейти к классу» или «перейти к определению».
Я знаю, что это проблема обучения; освобождение себя от физической файловой структуры проектов требует практики. Это очень полезно:)
Если вам удобно размещать их в одном файле, будьте моим гостем. Не могу сделать это с публичными классами в java хотя;)
Как правило, один класс/один файл - это путь. Тем не менее, я часто храню несколько описаний интерфейсов в одном файле. Несколько классов в одном файле? Только если они очень тесно связаны каким-то образом, и очень мало (< 5 методов и членов)
Один класс для каждого файла проще в обслуживании и гораздо более ясно, для кого-то еще смотрит на свой код. Он также является обязательным или очень ограниченным на некоторых языках.
В Java, например, вы не можете создавать несколько классов верхнего уровня для каждого файла, они должны быть в отдельных файлах, где имена классов и имена файлов одинаковы.
В Java один public класс на файл - это способ работы на языке. Группа файлов Java может быть собрана в пакет.
В Python, однако, файлы являются «модулями» и, как правило, имеют несколько тесно связанных классов. Пакет Python - это каталог, как и пакет Java.
Это дает Python дополнительный уровень группировки между классом и пакетом.
Существует не один правильный ответ, который является языковым агностиком. Это зависит от языка.
Правило, которое я всегда придерживаюсь, состоит в том, чтобы иметь один класс в файле с тем же именем. Я могу или не могу включать вспомогательные классы в этот файл в зависимости от того, насколько сильно они связаны с основным классом файла. Являются ли классы поддержки автономными или полезны сами по себе? Например, если метод в классе нуждается в специальном сравнении для сортировки некоторых объектов, это не мешает мне добавить класс функтора сравнения в тот же файл, что и метод, который его использует. Я не ожидал, что буду использовать его в другом месте, и это не имеет смысла, чтобы он был сам по себе.
Один класс в файле является хорошим правилом, но целесообразно сделать некоторые исключения. Например, если я работаю в проекте, где большинство классов ассоциировали типы коллекций, часто я буду держать класс и его коллекции в том же файле, например:
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
Лучшее правило является сохраняйте один класс за каждый файл, за исключением случаев, когда это начинает делать вещи сложнее, а не проще. Поскольку Visual Studio Find in Files настолько эффективен, вам, вероятно, не придется тратить много времени на просмотр файловой структуры.
Нет. Это плохой совет. Проконсультируйтесь с принятым ответом. Вы должны отделить репозиторий объектов от класса, который вы сохраняете. Это просто создает ненужную путаницу. – Hudson 2015-09-09 06:46:49
Как верно, так много времени в программировании, это сильно зависит от ситуации.
Например, что такое сплоченность рассматриваемых классов? Они плотно связаны? Являются ли они полностью ортогональными? Связаны ли они с функциональностью?
Это не было бы из линии для веба-рамки для подачи общего назначения widgets.whatever файла, содержащего BaseWidget, TextWidget, CharWidget и т.д.
пользователя рамок не будет из линии при определении файл more_widgets, содержащий дополнительные виджеты, которые они получают из виджетов фреймворков для своего конкретного пространства.
Когда классы ортогональны и не имеют ничего общего друг с другом, группировка в один файл будет действительно искусственной. Предположите приложение для управления роботизированной фабрикой, которая строит автомобили. Файл, называемый частями, содержащими CarParts и RobotParts, был бы бессмысленным ... вряд ли существует большая зависимость между заказом запасных частей для обслуживания и частями, которые завод производит. Такое объединение не добавило бы никакой информации или знаний о проектируемой системе.
Возможно, лучшее эмпирическое правило не ограничивает ваш выбор с помощью эмпирического правила. Правила большого пальца создаются для первого анализа разреза или для ограничения выбора тех, кто не способен сделать правильный выбор. Я думаю, что большинство программистов хотели бы верить, что они способны принимать правильные решения.
Нет, я не думаю, что это совсем плохая практика. Я имею в виду, что в целом лучше всего иметь отдельный файл для каждого класса, но есть, безусловно, хорошие случаи исключения, когда лучше иметь кучу классов в одном файле. Хорошим примером этого является группа классов исключений, если у вас есть несколько десятков из них для данной группы, действительно ли имеет смысл разделить отдельный файл для каждого из двух классов линейки? Я бы не стал спорить. В этом случае наличие группы исключений в одном классе гораздо менее громоздко и просто ИМХО.
Ответ Smalltalk: у вас не должно быть файлов (для программирования). Они делают лечение версий и навигацию болезненными.
Вам следует воздержаться от этого, если у вас нет веской причины.
Один файл с несколькими небольшими связанными классами может быть более читаемым, чем несколько файлов. Например, при использовании классов «case» для имитации типов union существует сильная взаимосвязь между каждым классом. Использование одного и того же файла для нескольких классов имеет преимущество, заключающееся в том, что они объединяются визуально для читателя.
В вашем случае автомобиль и дверь вообще не похожи друг на друга, и поиск класса двери в файле car.cs будет неожиданным, так что нет.
Поскольку ваш IDE Предоставляет вам «Перейдите к» функциональности и у вас есть некоторый контроль над разделяет пространства имен внутри ваших классов, то ниже преимущества наличия нескольких классов в одном файле, вполне стоит для меня ,
Родитель - дочерние классы
Во многих случаях я нахожу это весьма полезно иметь унаследованные классы в свой файл класса Base.
Это довольно просто, чтобы узнать, какие свойства и методы наследует ваш дочерний класс, и файл обеспечивает более быстрый обзор общей функциональности.
Public: Small - Helper - Классы DTO
Когда вам нужны несколько равнины и небольших классов для конкретной функциональности я нахожу это совершенно излишнее иметь файл со всеми ссылками и включает в себя в течение только 4-8 Liner класса .....
Код навигация также проще всего прокрутка над о пе файл вместо переключения между 10 файлов ... Его также легче рефакторингом, когда нужно изменить только одну ссылку вместо 10 .....
В целом нарушения правила Iron 1 класса в файл предоставляет дополнительные свободы, чтобы организовать ваш код.
Что происходит тогда, действительно зависит от вашей IDE, языка, командной коммуникации и навыков организации.
Но если вы хотите эту свободу, зачем жертвовать им за железное правило?
Как упоминалось в http://stackoverflow.com/questions/360643/is-it-a-bad-practice-to-have-multiple-classes-in-the-same-file/360675#360675, с общими инструменты навигации, которые вам не нужно перемещать по файлу в любом случае. Вместо этого вы перемещаетесь по классам/членам. – Suma 2011-04-05 15:25:24