Наименование типов в пространстве имен в соответствии с Руководством по проектированию .NET Framework

Question

У меня есть некоторые проблемы, чтобы придумать схему именования вменяемого типа для нашей новой линейки приложений. Я хочу следовать .NET Framework Руководству разработчика - Руководство по разработке для разработки библиотек классов , но я начинаю задумываться, а так ли это хорошая идея?

Я бы хотел использовать схему пространства имен Company.Product.Feature в качестве основы.

Задача 1: У нас есть собственный элемент управления и создаются базовые классы, и я хочу, чтобы они вошли в пространство имен Company.Product.Forms. Однако, согласно рекомендациям, мы не должны позволять именам наших типов быть Control или Form, даже если они находятся в нашем собственном пространстве имен Company.Product.Forms, так как они конфликтуют с системными типами.

Проблема 2: У нас есть несколько отдельных областей функций в приложении, и я хочу, чтобы они входили в их собственное пространство имен Company.Product.Feature. Многие из этих функций имеют похожий дизайн, с контроллером и некоторыми представлениями, поэтому в каждом пространстве имен Company.Product.Feature я хотел бы иметь типы с именами Controller, SomeView, AnotherView и т. Д. Однако в соответствии с рекомендациями у нас не должно быть одинаковых имен типов в разных пространствах имен.

Единственное решение, которое я вижу для преодоления этих проблем, состоит в том, чтобы префиксировать типы чем-то, что каким-то образом делает пространства имен избыточными. Или нет?

Answer 1

Microsoft явно поддерживает некоторую избыточность. Типичный пример:

System.Xml.XmlDocument

Общие имена классов, даже связанные в собственном именованном пространстве имен, могут вызвать головную боль у многих программистов, которые любят избегать полной квалификации своих экземпляров классов. «Документ» может быть документом XML, HTML или Word. Эта двусмысленность вызовет бесконечную путаницу, если вам случится импортировать более одного пространства имен с классом «Document».

Answer 2

Первый пост здесь, в StackOverFlow, на старый вопрос. Пожалуйста, будь добр со мной:)

Общие имена классов, даже связанные внутри надлежащего именованного пространства имен, могут вызвать головную боль у многих программистов, которые хотят избежать полной квалификации их экземпляров классов. «Документ» может быть документом XML, HTML или Word. Эта двусмысленность вызовет бесконечную путаницу, если вам случится импортировать более одного пространства имен с классом «Document».

Microsoft МОЖЕТ иногда способствовать некоторой избыточности, но это не всегда так. Что касается проблематики Document vs XMLDocument, когда вы знаете, что может быть несколько типов документов, почему бы просто не включить в объявление подходящую часть пространства имен?

Например: Xml.XmlDocument против Html.HtmlDocument

Вместо того, чтобы импортировать пространство имен XML и HTML, почему бы просто не включить содержащееся пространство имен? Стало бы так:

Xml.Document против Html.Document

Answer 3

Я бы предпочел Company.Product.UI, по некоторым причинам. Я бы тоже использовал это название для Интернета.

Относительно проблемы 1, если это базовые типы, вы можете включить Base в имя класса. Затем, как правило, у вас есть набор специфичных для домена элементов управления, которые не конфликтуют со встроенными типами. Если вы также сохраняете оболочки для общих элементов управления пользовательского интерфейса (TextBox, DropDownList и т. Д.), То я бы порекомендовал использовать для них префикс, может быть, этот префикс является сокращенным названием продукта. И затем, если вы сделаете это, то вы можете быть последовательными, и делать это для всех типов, независимо от того, являются ли они неоднозначными именами или нет.

Я говорю вам по собственному опыту. Вы будете постоянно зависать над переменными, чтобы увидеть их полные имена типов и т. Д., Вы будете использовать псевдонимы и т. Д. Код будет сложнее читать.

Проблема 2: На уровне GUI я склонен нарушать эти правила, потому что вам нужно согласованность имен (общие глаголы; Показать, Изменить, Список). Если руководство говорит вам иначе, я бы поверил, что это потому, что оно просто недостаточно конкретно.

Answer 4

Если это логично, тогда делайте это. Это всего лишь руководство, а не ЗАКОН. (не то, что ты тоже не можешь сломать это.)

Answer 5

Наличие классов с одинаковыми именами в разных пространствах имен просто противоречит рекомендациям по определенной причине, это делает чтение кода немного сложнее, потому что когда вы видите «Контроллер», вы должны мысленно сопоставить его с «Feature1». .Controller "или" Feature2.Controller ".

Я бы предпочел использовать Company.Product.Features.Feature1.Feature1Conroller с избыточной информацией или, возможно, Company.Product.Features.Feature1Controller, если это вас беспокоит (и мне лично не нравится иметь слишком много пространств имен). *

Но не стесняйтесь нарушать правила, существуют правила, которые заставят вас задуматься, прежде чем нарушать их: -)