Полезно ли добавлять новые классы в пространства имен фреймворка? - PullRequest
1 голос
/ 19 мая 2011

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

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

Ответы [ 3 ]

3 голосов
/ 19 мая 2011

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

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

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

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

CompanyName.TechnologyName

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

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

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

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

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

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

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

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

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

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

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

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

И:

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

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

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

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

3 голосов
/ 19 мая 2011

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

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

2 голосов
/ 19 мая 2011

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

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

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

Приветствия, Матиас

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...