У меня был один класс для одного файла. Например, car.cs имеет автомобиль класса. Но поскольку я программирую больше классов, я хотел бы добавить их в один и тот же файл. Например, car.cs имеет класс автомобиля и класс двери и т.д.
Мой вопрос хорош для Java, С#, PHP или любого другого языка. Должен ли я попытаться не иметь несколько классов в одном файле или это нормально?
Я думаю, вы должны попытаться сохранить свой код в 1 класс для каждого файла.
Я предлагаю это, потому что будет легче найти ваш класс позже. Кроме того, он будет работать лучше с вашей системой управления версиями (если файл изменится, то вы знаете, что определенный класс изменился).
Единственное время, когда я считаю правильным использовать более одного класса для каждого файла, является использование внутренних классов... но внутренние классы находятся внутри другого класса и поэтому могут быть оставлены внутри одного и того же файла. Роли внутренних классов сильно связаны с внешними классами, поэтому их размещение в одном файле отлично.
В Java один открытый класс для каждого файла - это способ работы языка. Группа файлов Java может быть собрана в пакет.
В Python, однако, файлы являются "модулями" и обычно имеют несколько тесно связанных классов. Пакет Python - это каталог, как и пакет Java.
Это дает Python дополнительный уровень группировки между классом и пакетом.
Нет никакого правильного ответа, который является языковым агностиком. Это зависит от языка.
Один класс для файла является хорошим правилом, но для некоторых исключений. Например, если я работаю над проектом, в котором большинство классов имеют связанные типы коллекций, часто я буду держать класс и его коллекцию в одном файле, например:
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
Лучшее эмпирическое правило состоит в том, чтобы сохранить один класс за каждый файл, кроме тех случаев, когда это начинает делать вещи сложнее, а не проще. Поскольку Visual Studio Find in Files настолько эффективен, вам, вероятно, не придется тратить много времени на просмотр файловой структуры.
Нет, я не думаю, что это плохая практика. Я имею в виду, что в целом лучше всего иметь отдельный файл для каждого класса, но есть, безусловно, хорошие исключения, где лучше иметь кучу классов в одном файле. Хорошим примером этого является группа классов исключений, если у вас есть несколько десятков из них для данной группы, действительно ли имеет смысл разделить отдельный файл для каждого из двух классов линейки? Я бы не стал спорить. В этом случае наличие группы исключений в одном классе гораздо менее громоздко и просто ИМХО.
Я обнаружил, что всякий раз, когда я пытаюсь объединить несколько типов в один файл, я всегда возвращаюсь назад и отделяю их просто потому, что он облегчает их поиск. Всякий раз, когда я объединяюсь, всегда есть момент, когда я пытаюсь вычислить wtf, я определил тип x.
Итак, теперь мое личное правило заключается в том, что каждый отдельный тип (за исключением, может быть, для дочерних классов, которым средний класс внутри класса, а не унаследованный класс) получает свой собственный файл.
Если вы работаете над командой, сохранение классов в отдельных файлах упрощает управление источником и снижает вероятность конфликтов (несколько разработчиков одновременно меняют один и тот же файл). Я думаю, что это облегчает поиск кода, который вы ищете.
Время только. Я рассматриваю расположение файлов, когда мне нужно создавать новые классы. В противном случае я никогда не буду перемещаться по файловой структуре. Я использую "перейти к классу" или "перейти к определению".
Я знаю, что это проблема обучения; освобождение себя от физической файловой структуры проектов требует практики. Это очень полезно, хотя;)
Если вам удобно размещать их в одном файле, будьте моим гостем. Не могу сделать это с публичными классами в java, хотя;)
Правило, которое я всегда выполняю, состоит в том, чтобы иметь один основной класс в файле с тем же именем. Я могу или не могу включать вспомогательные классы в этот файл в зависимости от того, насколько тесно они связаны с основным классом файла. Являются ли классы поддержки автономными или полезны сами по себе? Например, если метод в классе нуждается в специальном сравнении для сортировки некоторых объектов, это не мешает мне добавить класс функтора сравнения в тот же файл, что и метод, который его использует. Я не ожидал, что буду использовать его в другом месте, и это не имеет смысла для того, чтобы оно было само по себе.
Это может быть плохо с точки зрения будущего развития и ремонтопригодности. Гораздо легче запомнить, где класс Car, если у вас есть класс Car.cs. Где бы вы искали класс Widget, если Widget.cs не существует? Это автомобильный виджет? Это виджет двигателя? О, может быть, это виджет бублика.
Как правило, один класс/один файл - это путь. Тем не менее, я часто храню несколько описаний интерфейсов в одном файле. Несколько классов в одном файле? Только если они очень тесно связаны как-то и очень маленькие (< 5 методов и членов)
Как верно так много времени в программировании, это сильно зависит от ситуации.
Например, какова сплоченность рассматриваемых классов? Они плотно связаны? Являются ли они полностью ортогональными? Связаны ли они с функциональностью?
Нельзя было бы отключить веб-инфраструктуру для общих виджетах. Независимо от файла, содержащего BaseWidget, TextWidget, CharWidget и т.д.
Пользователь фреймворка не был бы вне линии в определении файла more_widgets, чтобы содержать дополнительные виджеты, которые они получают из виджетов фреймворка для своего конкретного пространства в домене.
Когда классы ортогональны и не имеют ничего общего друг с другом, группировка в один файл действительно была бы искусственной. Предположим, приложение для управления роботизированным factory, который создает автомобили. Файл, называемый частями, содержащими CarParts и RobotParts, был бы бессмысленным... вряд ли существует большая зависимость между заказом запасных частей для обслуживания и частями, которые производит factory. Такое объединение не добавило бы никакой информации или знаний о проектируемой системе.
Возможно, лучшее эмпирическое правило не ограничивает ваш выбор с помощью эмпирического правила. Правила большого пальца создаются для первого анализа разреза или для ограничения выбора тех, кто не способен сделать правильный выбор. Я думаю, что большинство программистов хотели бы верить, что они способны принимать правильные решения.
Вам следует воздержаться от этого, если у вас нет веских оснований.
Один файл с несколькими небольшими связанными классами может быть более читаемым, чем несколько файлов. Например, при использовании "классов случаев" для имитации типов профсоюзов между каждым классом существует сильная взаимосвязь. Использование одного и того же файла для нескольких классов имеет то преимущество, что они объединяются визуально для читателя.
В вашем случае автомобиль и дверь вообще не похожи друг на друга, и поиск класса двери в файле car.cs будет неожиданным, так что не делайте этого.
Так как ваша IDE Предоставляет вам функциональность Перейдите к ", и у вас есть некоторый контроль над namespacing внутри ваших классов, то нижеприведенные преимущества иметь несколько классов в одном файле, для меня это вполне достойно.
Родительские - дочерние классы
Во многих случаях мне очень полезно иметь Inherited классы в файле класса Base.
Теперь довольно легко увидеть, какие свойства и методы наследует ваш дочерний класс, и файл обеспечивает более быстрый обзор общей функциональности.
Public: Small - Helper - классы DTO
Если вам нужны несколько классов plain и small для специфических функций, я считаю, что он достаточно избыточен, чтобы иметь файл со всеми ссылками и включает только класс 4-8 Liner.....
Навигация по коду также проще просто прокручивать один файл вместо переключения между 10 файлами... Его также проще рефакторинг, когда вам нужно редактировать только одну ссылку вместо из 10.....
Общее нарушение правила Железо 1 класса на файл предоставляет дополнительную свободу для организации вашего кода.
Что происходит тогда, действительно зависит от ваших IDE, языка, командной коммуникации и навыков организации.
Но если вы хотите эту свободу, зачем жертвовать ею за железное правило?
Один класс для каждого файла проще в обслуживании и гораздо более понятный для всех, кто смотрит на ваш код. Он также является обязательным или очень ограниченным на некоторых языках.
В Java, например, вы не можете создавать несколько классов верхнего уровня для каждого файла, они должны быть в отдельных файлах, где имена классов и имена файлов одинаковы.
Ответ Smalltalk: у вас не должно быть файлов (для программирования). Они делают больший перенос версий и навигации.