Должны ли я использовать (иначе оптимальные) имена классов, которые конфликтуют с именами .NET BCL?

Ответ 1

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

using Type = MyReallyCoolCustomReflector.Type;

Теперь, если вы хотите использовать класс Type из пространства имен System:

System.Type sysType = anObject.GetType();

Как правило, я стараюсь избегать дубликатов имен, но это не всегда так получается. Мне также нравится простой, читаемый и поддерживаемый код. Так часто это решение является компромиссным.

Ответ 2

Я не вижу проблемы с сохранением имен Drawing, Diagnostics и т.д. Это одна из целей пространств имен, чтобы разрешить конфликты имен.

Ответ 3

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

using MyAlias = My.Custom.Namespace;

это будет держать ваши классы отдельно от Microsoft.

вы можете ссылаться на свои классы как

MyAlias.Diagnostics

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

Ответ 4

Для меня действительно не стоит хлопот целенаправленно писать конфликтующие имена классов. Вы будете путать других разработчиков, которые не знакомы с вашей кодовой базой, потому что они будут ожидать использования классов BCL, но в конечном итоге вместо вас (или наоборот). Затем вы просто теряете время, когда им приходится писать конкретные псевдонимы using.

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

EDIT. Я также не считаю, что "маленький" является компонентом "идеального" идентификатора. Разумный и понятный, но, если требуется более длинное имя, чтобы передать цель конкретной конструкции, пусть будет так. В конце концов, у нас есть intellisense.

Ответ 5

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

• Не сталкивайтесь, вместо этого выберите уникальное имя.

Пример:

Если вы создаете класс Math, вы можете назвать свой CamiloMartin.MathHelper

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

Пример:

public class MyClass
{
    public int SomeCalculation(int a, int b)
    {
        return MyNamespace.Math.SomeFunc(a, b);
    }
}

• Использование псевдонима для дифференциации.

Пример:

using System.Math;
using SuperMath = MyNamespace.Math;

namespace MyNamespace
{
    public class MyClass
    {
        public int SomeCalc(int a, int b)
        {
             int result = Math.abs(a);
             result = SuperMath::SomeFunc(a, b);

             return result;
        }
    }
}

Ответ 6

Только для записи:.NET framework не имеет ни класса Utils, ни Diagnostics. (Но имеет System.Diagnostics пространство имен.)

Лично мне не нравятся классы общего назначения, такие как Utils, потому что их методы не очень доступны для поиска (и обычно либо слишком общие, либо слишком специфичные), поэтому я бы оправдывал их использование только как для внутренних классов.

Что касается остальных - я согласен с другими в том, что пространства имен удобны. (Хотя я бы подумал дважды, чтобы назвать класс, если уже есть класс в System с тем же именем, а не из-за конфликтов имен, а скорее из-за того, что причина, по которой я не могу использовать "оригинальный" класс, может означать, что класс, который я собираюсь создать, семантически отличается.)

Ответ 7

Часто его можно выбрать более конкретное имя. Возьмите Utils, например. Абсолютно все можно назвать утилитацией. Для читателя вашего кода это имя класса бесполезно.

Часто классы полезности представляют собой набор методов, которые не подходят нигде. Попытайтесь разместить их там, где они есть, или сгруппируйте их по некоторым критериям, а затем используйте группу как имя класса. Такая группировка в моем опыте всегда возможна.

В общем:

• Что мы делаем (эй, мы можем реорганизовать его позже)

• Используется один или два раза, но только для важных классов. Особенно полезно, если вы еще не знаете "идеального" имени.

• даже не думайте об этом...

Использование псевдонимов пространства имен - не забава. Поэтому я избегаю этого, если смогу.