Сколько классов программист должен поместить в один файл?
Каким руководящим принципам вы следуете в своем объектно-ориентированном языке для группировки классов в один файл? Вы всегда даете каждому классу отдельный файл? Вы собираете вместе тесно связанные классы? Вы когда-нибудь указывали пару реализаций интерфейса в одном файле? Делаете ли вы это на основании того, сколько строк кода может быть в реализации или насколько «загроможденной» она может выглядеть для пользователя класса? Или пользователь предпочел бы, чтобы все было в одном месте?
Итак .. вы говорите, что у вас может быть больше одного класса?
Кажется тесно связанным с stackoverflow.com/questions/360643/…
Ответы 11
Я думаю, что лучшие практики для всех объектно-ориентированных языков, которые я когда-либо использовал, - это иметь один класс в одном файле. Я считаю, что это может потребоваться для некоторых языков, но я не уверен в этом. Но я бы сказал, что один класс на файл и имя файла, соответствующее имени класса (а также структура каталогов, соответствующая структуре пакета по большей части), являются лучшей практикой.
Java - это пример языка, которому требуется один класс верхнего уровня для каждого файла.
Я так и думал, но не был уверен. Я совершенно уверен, что ActionScript - еще один пример.
Код Python обычно не содержит всех классов в отдельном файле. Каждый файл является «модулем», а связанные классы обычно сгруппированы в один модуль.
Старые разновидности VB (4–6) были такими же, один файл класса - один класс.
Кент, у вас может быть только один общедоступный класс для каждого файла в Java, но вы можете дополнительно иметь несколько (верхнего уровня, не являющихся членами) закрытых для пакета (также называемых видимостью по умолчанию) классов в одном файле.
@Fabian, Ryan: аналогично для ActionScript
Это хорошее базовое руководство. Но я думаю, что, как и в случае с большинством руководящих принципов, иногда есть веские причины не следовать им.
Лично я предлагаю один класс для каждого файла пока не, вторичные классы являются частными для основного класса в файле. Например, вложенный класс в C# останется в файле родительских классов, но служебные классы, которые мощь будут полезны в другом месте, будут разбиты на их собственный файл или даже пространство имен.
Ключ в том, чтобы понять ваше окружение и то, где люди будут искать вещи. Если существует устоявшаяся методология, хорошенько подумайте, прежде чем расстраивать ее. Если ваши коллеги ожидают, что связанные, тесно связанные классы будут в одном документе, необходимость их поиска может раздражать (хотя с современными IDE это не должно быть проблемой).
Дополнительная причина разбивать файлы на большее количество файлов, а не на меньшее, - это контроль версий. Если вы сделаете небольшое изменение, оно должно изменить только небольшой файл, где это возможно. Если вы сделаете радикальное изменение, это станет очевидным при просмотре журналов, поскольку все файлы (и косвенно классы), которые были затронуты, были отмечены.
В C# вы можете поместить внутренний класс в отдельный файл. С помощью ключевого слова "partial" вы можете разделить класс на несколько файлов (хотя чрезмерное использование этого слова является явным признаком того, что у класса слишком много обязанностей).
Ну да ... но я не уверен, что обычно хотел бы это делать. Partial отлично подходит для конструктора пользовательского интерфейса, поскольку он скрывает неприятные детали от программиста. С другой стороны, частичная реклама сложности структуры решения, поэтому я бы старался избегать этого пока не, это было для метапрограммирования, как пользовательский интерфейс.
Да, UI-дизайнер - это форма метапрограммирования. Если легко расширить поверхность дизайна пользовательского интерфейса с помощью ваших собственных элементов управления и написать код, который генерирует эффекты как во время разработки, так и во время выполнения, я не уверен, как это не соответствует определению «программа, которая манипулирует собой или другими программами».
Разница в том, что вы не писали UI-дизайнер, вы просто его используете. Так что это не более мета, чем использование текстового редактора.
Я думаю, мы соглашаемся друг с другом. Я сказал: «Частичное отлично подходит для построителя пользовательского интерфейса» и «если только оно не предназначено для метапрограммирования, такого как пользовательский интерфейс». Я думаю, что partial - это отлично для разработчиков пользовательского интерфейса, но если вы не делаете подобную метапрогамминг, я нахожу это довольно раздражающим.
(Для ясности: авторы конструктора пользовательского интерфейса находятся занимаются метапрограммированием, которое делает использование частичного прощения. Я делаю то же самое с конструктором цитат для нашего страхового продукта: мы используем частичные данные в выводе генерации кода для расчета / отображать подпрограммы.)
Один класс = один файл. Всегда. За исключением случаев, когда один класс = несколько файлов в C# или класс содержит внутренние классы и т. д., Конечно;)
Один на файл - наш стандарт. Единственное исключение - это то, что для класса и его типизированной коллекции мы собираем их вместе.
Со временем я осознал, что этот «маленький класс» всегда имеет тенденцию к росту. А потом вы захотите разделить их, запутав всех остальных в команде (и себя).
Я помещаю классы в один файл, если они принадлежат друг другу, по техническим или эстетическим причинам. Например, в приложении, которое предоставляет интерфейс плагина, классы Плагин (базовый класс для плагинов) и PluginManager я обычно объединяю в один файл. Однако, если файл становится слишком большим, на мой вкус, я бы разделил его на отдельный файл.
Отмечу, что сейчас я пишу код в основном на Python, и это влияет на мой дизайн. Python очень гибок в том, как я могу разделить вещи на модули, и имеет хорошие инструменты для управления пространствами имен вещей. Например, я обычно помещаю весь код приложения в модуль Python (каталог с __init__.py) и заставляю модуль импортировать определенные имена из подмодулей. Тогда API будет чем-то вроде applib.PluginManager, а не applib.pluginstuff.PluginManager.
Это позволяет легко перемещать вещи, что также позволяет мне не быть таким привередливым, когда я создаю дизайн: я всегда могу исправить вещи позже.
Я считаю, что для Python, в частности, вам нужны тесно связанные классы в одном файле. Это связано с тем, что механизм импорта Python может вызвать мигрень, если два разных файла должны зависеть друг от друга, потому что они содержат классы, которые взаимозависимы. Другие языки лучше работают с подходом «один класс на файл». Java, конечно, поддерживает этот подход, по крайней мере, для общедоступных классов.
Я стараюсь сохранять один класс для каждого файла (как и большинство вышеперечисленных), если только они не являются небольшими классами. Если их много, я могу разбить их по тематикам в противном случае. Но обычно я просто храню их все в одном файле с свертыванием кода в редакторах. Для моих личных хаков это просто не стоит (минимальных) усилий для меня.
Не существует жесткого правила, которому нужно всегда следовать (если его не предписывает конкретный язык). Есть веские причины для того, чтобы иметь только один класс или иметь несколько классов в файле. И это действительно зависит от языка.
В C# и Java люди склонны придерживаться одного файла на класс.
Я бы сказал на C++, хотя я часто помещаю несколько классов в один файл. Часто эти классы небольшие и очень взаимосвязанные. Например. Один класс для каждого сообщения в каком-либо протоколе связи. В этом случае файл для каждого будет означать много файлов и фактически затруднит обслуживание и чтение кода, чем если бы они были в одном файле.
В C++ реализация класса отделена от определения класса, поэтому каждый класс {/ тело /} меньше, чем в другом языке, и это означает, что классы имеют более удобный размер для группировки в один файл.
В C++, если вы пишете библиотеку (например, стандартную библиотеку шаблонов), вы можете поместить все классы в один файл. Пользователям нужно включить только один файл заголовка, и тогда они получат все классы, так что им будет легче работать.
Баланс есть. Ответ - все, что легче всего понять и поддерживать. По умолчанию имеет смысл иметь один класс для каждого файла, но есть множество случаев, когда более практично работать со связанным набором классов, если они определены в одном файле.
Мне нравится, как в вашем ответе рассматриваются обе стороны вопроса. Однако можно получить лучшее из обоих миров в C++, включив несколько файлов заголовков в один файл, который пользователи могут включить. Фактически, стандартная библиотека GNU активно использует эту технику.
@ Jørgen Fogh Я не уверен, что это лучшее из обоих миров! Если у вас много маленьких классов в одном файле, вам нужно работать только с одним файлом. Если вы поместите все классы в отдельные файлы и используете много включений, у вас внезапно появится больше работы по управлению и навигации между этими файлами, если вы хотите их редактировать, и вам нужно синхронизировать все включения! Я предполагаю, что если вы рассматриваете только с точки зрения пользователя классов, ваш метод может быть простым, но для автора классов это будет больше работы. Учитывайте как пользователя, так и автора. :)
Правда. Это зависит от контекста. Что касается стандартной библиотеки, то следует рассматривать только пользователей, так как пользователей очень много по сравнению с количеством сопровождающих библиотеки. В других ситуациях компромисс может быть другим.
Один класс на файл кажется стандартом. Я тоже так обычно поступаю.
Было несколько раз, когда я отклонялся от этого. В частности, когда меньший класс является членом другого класса. Например, при разработке структуры данных я, скорее всего, реализовал бы класс «узел» в том же файле, что и класс «большая структура».
1 класс = 2 файла. An .h и .c, вы, детки, такие удачливые :)
upvote :) Если вы не пишете шаблонный класс или не хотите, чтобы все было встроено.
Вы думаете, что это плохо, .Net позволяет вам использовать столько файлов, сколько вы хотите, с помощью магии частичных классов. Классы веб-страниц по умолчанию имеют 3 файла.
LOL, но я думал, что .h и .c предназначены для C (у которого нет классов), тогда как соглашение C++ - .hpp и .cpp
Кибби, вы можете сделать то же самое в C++, поместив #includes в неудобные места. Это не значит, что вам следует.
In your object-oriented language, what guidelines do you follow for grouping classes into a single file?
По-разному. В командной работе я стараюсь следовать командным стандартам; в сольной работе я больше склоняюсь к тому, что мне нравится.
Тогда в сольной работе ...
Do you always give each class a seperate file? Do you put tightly coupled classes together? Have you ever specified a couple of implementations of an interface in one file?
Нет. Иногда. Да.
Do you do it based on how many lines of code the implementation might be or how "cluttered" it might look to the user of the class? Or would the user prefer to have everything on one place?
В основном это основано на:
- Насколько легко ориентироваться? Огромный длинный исходный файл с множеством классов сложнее.
- Насколько легко редактировать? При редактировании нескольких коротких связанных классов может быть проще, если они все в одном исходном файле с разделителем, чем если они находятся в нескольких исходных файлах, учитывая, что я запускаю свой текстовый редактор в развернутом виде, показывая по одному исходному файлу за раз. .
Я предпочитаю 1 к 1 для классов, если только внутренний класс не будет полностью приватным. Даже в этом случае я обычно разбиваю его, чтобы упростить поиск и отслеживание изменений в SVN.
Вам разрешено создавать несколько файлов? Почему я все это время помещал все свое приложение в один файл? :П