Рекомендации по именованию классов/методов C#, предназначенных для замены существующих API

Помимо длинного объяснения, у меня есть ситуация, когда мне нужно в основном повторно реализовать класс .NET framework, чтобы расширить поведение таким образом, который не совместим со стратегией наследования или композиции/делегирования. Вопрос не в том, является ли курс действий, который я должен предпринять, тем, что вы бы сделали или рекомендовали, это скорее вопрос именования/стиля кодирования.

Существует ли парадигма для именования классов и методов, которые имеют ту же функциональность, что и существующий класс или метод ala соглашение ClassEx / MethodEx, которое существует в C++?

[править]
Я понимаю, что выбор хороших имен для этого очень важен... Я еще не написал ни строчки кода, а вместо этого трачу время на обдумывание последствий того, что я собираюсь предпринять, и это включает в себя поиск ясного, описательного названия, пытаясь быть кратким. Проблема в том, что имя, которое я имею в виду, не очень лаконично.
[/edit]

777 4

c++naming-conventions coding-style

4 ответов:

Comments

Ничего не найдено.

Jason Kresowaty · Accepted Answer · 2009-11-28 01:50:16

Вот способы, которые я видел в самой платформе .NET Framework:

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

Поместите его в другое пространство имен. Например, WPF Button находится в System.Windows вместо System.Windows.Forms.

Суффикс его с номером. Например, X509Certificate2 против X509Certificate. (Эта практика была распространена с COM-интерфейсами, но упала в немилость . Чистая.)

Обратите внимание, что именование TimeZoneInfo является публичным случаем Microsoft, решающим эту проблему конвроверциального именования в лоб. Смотрите и http://blogs.msdn.com/kathykam/archive/2007/03/28/bye-bye-system-timezone2-hello-system-timezoneinfo.aspx и http://blogs.msdn.com/kcwalina/archive/2006/10/06/TimeZone2Naming.aspx за отличную информацию.

DxCK · Accepted Answer · 2009-11-28 02:03:08

Попробуйте назвать свои классы / методы с реальным значением.

Например, если вы расширяете функцию Random для создания случайных строк, назовите класс StringRandom или StringRandomizer и так далее.

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

Если вы пишете наугад.Следующий метод, который возвращает случайное число между minValue и maxValue, включая maxValue, назовите метод NextIncludingMaxValue.

Если вы пишете очередь.Метод Dequeue, который является потокобезопасным, назовите, если DequeueThreadSafe.

Если вы пишете очередь.Метод Dequeue, который блокирует до тех пор, пока другой поток не поставит элемент в очередь, назовите его Dequeublocking.

И тому подобное...

Reed Copsey · Accepted Answer · 2009-11-28 01:32:46

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

В отличие от C++, в C# есть немного причин для этого. В C++ добавление метода нарушает совместимость, поэтому "Ex" становится гораздо более распространенным сценарием.

ChrisW · Accepted Answer · 2009-11-28 02:43:19

Я даю всем моим методам (и свойствам) имена camelCase: так, например Invalidate - это имя метода фреймворка, а invalidate - имя одного из моих методов.

Это (используя названия camelCase) нетрадиционно, поэтому некоторые люди возражают против этого, но я нахожу это удобным.

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