views:

187

answers:

4

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]

A: 

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.

Reed Copsey
+3  A: 

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.

binarycoder
Good linkage... I especially appreciate the blog post from Krzysztof Cwalina. His book on framework design guidelines is a great read.
Blackened
+1  A: 

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...

DxCK
A: 

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.

ChrisW
To address you final point, namespaces are not the silver bullet. Consider the following:You decide for whatever reason to make a replacement for a web control called System.Web.UI.WebControls.Foo, with your class YourCompany.Web.UI.WebControls.Foo. In ASP.NET, you'd be silly not to "using" System.Web.UI.WeCcontrols, and if you want to use your control via codebehind, you'd "using" YourCompany.Web.UI.WebControls. You now have two symbols with the same name in the current scope... a Foo from each.I don't care for "using" aliases and absolute references... So class names are important.
Blackened
If I replace a class, it tends to have additional decorator-like functionality (which can disambiguate its name: e.g. it's not a Foo, it's a FooWithTooltips), or it's used instead of (not as well as) the other class (for example it's a ClientSideProxy.Foo as opposed to a ServerSideImplementation.Foo). I'm not saying you're wrong, just that I've never had the same problem as you.
ChrisW
Two other things you could do: a) don't use a `using` statement at all, and instead use the namespace-qualified classname in your code (for example `MyNamespace.Foo`); or, b) use the using` statement to ellide the namespace name with the classname (for example `using MyNamespaceFoo = MyNamespace.Foo;`).
ChrisW