Полезно ли добавлять новые классы в пространства имен фреймворка?

Question

Давным-давно я помню, как читал довольно сильную рекомендацию Microsoft не добавлять свои собственные классы в пространства имен фреймворка. Я безуспешно искал это.

Основная причина, которую я помню, заключается в том, что последующая версия фреймворка может поставляться с конфликтом имен классов.

Есть ли другие причины? Вы когда-нибудь рекомендовали бы добавлять свои собственные классы в пространство имен фреймворка? Есть ли какое-либо официальное руководство по этому вопросу?

Answer 1

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

Например, я написал реализацию HashSet и поместил в пространство имен System.Collections.Generic для приложения, которое предназначалось для.NET 2.0, когда.NET 3.5 находился в бета-версии. Я знал, что мы перейдем на.NET 3.5 и удалим этот класс, когда придет время.

Answer 2

Кажется, здесь довольно четко сказано:

Соглашения об именах

Типы.NET Framework используют схему именования с точечным синтаксисом, которая обозначает иерархию. Этот метод группирует связанные типы в пространства имен, чтобы их можно было легче искать и ссылаться на них. Первая часть полного имени - до крайней правой точки - это имя пространства имен. Последняя часть имени - это имя типа. Например, System.Collections.ArrayList представляет ArrayList тип, принадлежащий пространству имен System.Collections. Типы в System.Collections может использоваться для управления коллекциями объектов.

Эта схема именования позволяет разработчикам библиотек, расширяющим.NET Framework, создавать иерархические группы типов и называть их согласованным и информативным образом. Это также позволяет однозначно идентифицировать типы по их полному имени (то есть по пространству имен и имени типа), что предотвращает конфликты имен типов. Ожидается, что разработчики библиотек будут использовать следующие рекомендации при создании имен для своих пространств имен:

CompanyName.TechnologyName

Например, пространство имен Microsoft.Word соответствует этому руководству.

И "Рекомендации по разработке библиотек классов" имеют аналогичное правило:

Общий формат для имени пространства имен выглядит следующим образом:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Например, Microsoft.WindowsMobile.DirectX.

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

Используйте стабильное, независимое от версии имя продукта на втором уровне имени пространства имен.

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

Имя пространства имен является долгоживущим и неизменным идентификатором. По мере развития организаций изменения не должны делать имя пространства имен устаревшим.

Используйте регистр Pascal и разделяйте компоненты пространства имен точками (например, Microsoft.Office.PowerPoint). Если в вашем бренде используется нетрадиционный корпус, вы должны следовать описанию, указанному вашим брендом, даже если он отличается от обычного корпуса имен.

Рассмотрите возможность использования множественных имен пространства имен, где это уместно. Например, используйте System.Collections вместо System.Collection, Однако торговые марки и сокращения являются исключениями из этого правила. Например, используйте System.IO вместо System.IOs,

Не используйте одно и то же имя для пространства имен и тип в этом пространстве имен. Например, не использовать Debug для имени пространства имен, а также предоставить класс с именем Debug в том же пространстве имен. Некоторые компиляторы требуют, чтобы такие типы были полностью квалифицированы.

А также:

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

Не указывайте имена типов, которые будут конфликтовать с любым типом в основных пространствах имен.

Например, не использовать Directory как имя типа, потому что это будет конфликтовать с Directory тип.

Но, конечно, вы можете сделать это, если вы действительно хотите.

Answer 3

Есть рекомендация использовать Company.Product.Component как пространства имен. Это может включать в себя не использование пространств имен Framework в вашем собственном продукте, я думаю. См. MSDN: Имена пространств имен (Руководство по разработке для разработки библиотек классов).

Лично я бы никогда не использовал System пространство имен для моих собственных классов, так же как они не принадлежат.NET Framework. Ни я бы не использовал java.lang на Яве. Впрочем, это только мое личное мнение.

Надеюсь, это поможет.

Ура, Матиас