MichaelFStarke
MichaelFStarke

Reputation: 53

Recommendations for naming C# classes/methods intended to replace existing APIs

Long explanation aside, I have a situation where I need to basically re-implement a .NET framework class in order to extend the behavior in a manner that is not compatible with an inheritance or composition/delegation strategy. The question is not a matter of whether the course of action I am to take is what you would do, or recommend, it is instead a question of naming/coding-style.

Is there a paradigm for naming classes and methods that have the same functionality as an existing class or method ala the convention of ClassEx/MethodEx that exists in C++?

[edit] I understand that choosing good names for this is important... I haven't written a line of code yet, and am instead taking the time to think through the ramifications of what I am about to undertake, and that includes searching for a clear, descriptive, name while trying to be concise. The issue is that the name I have in mind is not terribly concise. [/edit]

Upvotes: 4

Views: 801

Answers (4)

ChrisW
ChrisW

Reputation: 56113

I give all my methods (and properties) camelCase names: so for example Invalidate is a framework method name, and invalidate is the name of one of my methods.

This (using camelCase names) is unconventional, so some people object to it, but I find it convenient.

No such problem with class names (for which I use the conventional UpperCase), because for class names there are their namespaces to distinguish them from the framework classes.

Upvotes: 0

DxCK
DxCK

Reputation: 4552

Try name your classes/methods with real meaning.

For example, if you extending the Random functionality to create random strings, name the class StringRandom or StringRandomizer and such.

If you writing class with general purpose extension methods that applying to specific class/interface, for example IList, name it ListExtensions.

If you writing random.Next method that returns random number between minValue and maxValue including maxValue, name the method NextIncludingMaxValue.

If you writing queue.Dequeue method that is thread safe, name if DequeueThreadSafe.

If you writing queue.Dequeue method that blocking until other thread enqueueing an item, name it DequeueBlocking.

And such...

Upvotes: 1

Jason Kresowaty
Jason Kresowaty

Reputation: 16500

Here are the ways I've seen in the .NET Framework itself:

  1. Call it something slightly different, but don't use any specific suffix. For example, System.TimeZoneInfo was introduced to supersede System.TimeZone.

  2. Put it in another namespace. For example, the WPF Button is in System.Windows instead of System.Windows.Forms.

  3. Suffix it with a number. For example X509Certificate2 versus X509Certificate. (This practice was common with COM interfaces but has fallen out of favor in .NET.)

Note that the naming of TimeZoneInfo is a publicized case of Microsoft tackling this convtrovertial naming issue head on. See and http://blogs.msdn.com/kathykam/archive/2007/03/28/bye-bye-system-timezone2-hello-system-timezoneinfo.aspx and http://blogs.msdn.com/kcwalina/archive/2006/10/06/TimeZone2Naming.aspx for excellent information.

Upvotes: 5

Reed Copsey
Reed Copsey

Reputation: 564383

C#, for the most part, avoids these situations entirely due to the ease in which you can extend a class with new methods without breaking binary compatibility (you can add methods, at will, to a class, just not an interface), and through the use of Extension methods.

There are few reasons to ever do this in C#, unlike C++. In C++, adding a method breaks compatibility, so "Ex" becomes a much more common scenario.

Upvotes: 0

Related Questions