Ответ на этот вопрос не является абсолютным, так как он часто зависит от поставленной задачи. Если вы создаете какой-то SDK для повторного использования другими, тогда пространства имен очень важны; однако, если вы создаете собственный инструмент с помощью всего нескольких классов, пространства имен в значительной степени не важны.
Классы
Вообще говоря, у классов должен быть свой собственный файл, так как это упрощает процесс навигации по решению кода, помогая в разработке и обслуживании (например, объединить изменения гораздо сложнее, когда все изменяют одни и те же файлы). Может быть приемлемо разделить один класс на несколько файлов в некоторых ситуациях, таких как:
При наличии вложенных классов каждый вложенный класс может иметь свой собственный файл.
Когда в классе есть автоматически сгенерированные части, например код конструктора.
Когда в классе есть фиксированные части, такие как общий набор скрытых свойств или общая реализация интерфейса.
В одном из наших проектов у нас есть общая реализация интерфейса, которую предоставляют многие классы. Поскольку у нас нет множественного наследования, мы используем смешанный подход, при котором мы автоматически генерируем дополнительный файл для каждого класса. Это можно сделать вручную, а не автоматически (и было изначально).
Существуют и другие ситуации, но это несколько субъективно и зависит от требований вашего собственного проекта.
1025 * Namespaces *
Пространства имен обычно должны фокусироваться на разумных группировках ваших типов. Пространство имен должно позволить разработчику интуитивно найти то, что он ищет. Для многих небольших проектов достаточно одного пространства имен, например MyAwesomeTool, но для более крупного проекта со многими классами потребуется более логичная группировка. Такие крупные проекты, такие как SDK или .NET BCL, полагаются на пространства имен, чтобы разбить огромную коллекцию типов. Каждый уровень пространства имен предоставляет дополнительную информацию о том, что там может быть найдено, например, System.Windows.Forms или System.Drawing или Microsoft.VisualBasic.
При создании пространств имен необходимо учитывать все цели этого пространства имен и связанного с ним проекта. Если проект внутренний и небольшой, назовите пространство имен так, как вам нравится, поскольку это просто необходимость группировки ваших типов; если проект является видимым извне или содержит большое количество типов, тщательно продумайте логические и содержательные группировки, которые позволят другим интуитивно найти нужные им типы.
Заключение
Нет жестких и быстрых правил, которые работают в любой ситуации. То, как вы организуете свой код в файлы, зависит от ваших собственных процессов разработки, влияющих на вас и вашу команду; все ваши классы в одном файле будут адскими разработками, но скомпилированный продукт не будет действовать по-другому (при условии, что подход с одним файлом не приведет к ошибкам), тогда как расположение ваших пространств имен относится к будущей разработке и потребителям эти пространства имен, поэтому последствия неправильного понимания могут быть более серьезными.
- Целью организации ваших занятий таким образом, чтобы упростить текущую разработку и дальнейшее обслуживание.
- Стремитесь организовать свои пространства имен таким образом, чтобы упростить всю разработку и, при необходимости, опыт ваших конечных пользователей.