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

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

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

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

Ответы [ 4 ]

5 голосов
/ 28 ноября 2009

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

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

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

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

Обратите внимание, что присвоение имени 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 для получения превосходной информации.

1 голос
/ 28 ноября 2009

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

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

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

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

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

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

И такой ...

0 голосов
/ 28 ноября 2009

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

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

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

0 голосов
/ 28 ноября 2009

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

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

...