6

What is the most concise (yet descriptive) way of naming a subclass that only add a specific minor thing to the parent? I encountered this case a lot in WPF, where sometime I have to add a small functionality to an out-of-the-box control for specific cases.

Example: TreeView doesn't change the SelectedItem on right-click, but I have to make one that does in my application.

Some possible names are

  • TreeViewThatChangesSelectedItemOnRightClick (way too wordy and maybe difficult to read because there is so many words concantenated together)
  • TreeView_SelectedItemChangesOnRightClick (slightly more readable, but still too wordy and the underscore also breaks the normal convention for class names)
  • TreeViewThatChangesSIOnRC (non-obvious acronym),
  • ExtendedTreeView (more concise, but doesn't describe what it is doing. Besides, I already found a class called this in the library, that I don't want to use/modify in my application).
  • LouisTreeView, MyTreeView, etc. (doesn't describe what it is doing).

It seems that I can't find a name which sounds right. What do you do in situation like this?

Community
  • 1
Louis Rhys
  • 6,042
  • 11
  • 42
  • 59
  • I would give it a short, somewhat descriptive name but avoid to write every detail. TreeViewRightClickExtension or maybe use a very well known abbreviation like TreeView_RMB_ItemSelect or TreeViewRmbItemSelect. But would depend on the amount of such classes in my project. The more classes, the more details in the name. – thorsten müller Nov 20 '12 at 12:21
  • 1
    why not add a mouse listener/handler that does the selection? – ratchet freak Nov 20 '12 at 12:38
  • @ratchetfreak I want it to be reusable in several places, and I am using it inside some DataTemplates too.. so I decided to create a class.. Regardless of the decision, my question is about the naming of such classes – Louis Rhys Nov 20 '12 at 13:07

3 Answers3

5

If your application is supposed to use both the original, non-right-sensitive version and your own improved version, then the name absolutely has to express what the derived class does. Otherwise everyone navigating the code base will go nuts understanding what the difference is and where it applies or not. Something like RightSensitiveTreeView is probably your best bet, even though it is already clumsy and will become much more clumsy if you ever need to express more than one extended behaviour.

But if you use the extended version exclusively, there is little harm in using a euphonious, even proud name like LouisTreeView - it will stay accurate even if you add more enhancements later, since those presumably will also be used everywhere. The only thing you should not do is reuse the original name exactly and disambiguate by putting it into a different package path. That is just asking for confusion.

(Disclaimer: proverbially, there are only two really hard things in computer science - cache invalidation and naming things. This is my opinion, but people will probably come forward with very different views.)

gnat
  • 21,442
  • 29
  • 112
  • 288
Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • for the second case you could even just use namespace to differentiate – jk. Nov 20 '12 at 13:20
  • 1
    and concurrency isn't hard? – ratchet freak Nov 20 '12 at 13:25
  • @ratchetfreak cache invalidation is one of the toughest _concurrency_ problems. I find naming [slightly](http://programmers.stackexchange.com/questions/129961/are-there-good-techniques-or-tests-for-naming-types/129968#129968) harder though – gnat Nov 20 '12 at 13:45
3

For a single class like your TreeView subclass that just adds a small amount of functionality, it's probably not necessary to try too hard to make a good name. Personally I would make do with CustomTreeView or similar. Then the actual "Custom" bit can be described in some docs or comments above the class definition.

However suppose you have several of these classes, each extending TreeView in some small way. Then a generic name like the above wouldn't cut it. You could attempt to name each customisation descriptively but then you things could go south - "RightSensitiveTreeView" for example is a bit lengthy for a class name.

If you want to add bits of functionality to a class, consider this approach: Create one subclass in your application (or personal/company library) and call it CustomTreeView or whatever. Make it work identically to TreeView by default. Add properties/methods that enable/disable the extended functionality - say, a selectOnRightClick property would do nicely for your extension. Then you can add as many customisations as you like to your one subclass, and all code that uses your subclass automatically has access to those customisations, with minimal change to code.

Michael Slade
  • 1,031
  • 8
  • 9
  • I would even say that for `CustomTreeView` it's worth to create an interface for extra behaviour. Many properties makes it only more difficult to use when compared to specifying an instance of the interface at construction time. – SpaceTrucker Nov 20 '12 at 18:04
2

If it's just generic functionality that will probably be wanted anytime you use such a control, such as changing items on right-click, I usually just add Ex to the end of my class to signify it's an extended version of the class. For example, TreeViewEx or TabControlEx

The actual word being used doesn't really matter, but I do try and keep it consistent throughout all my customized classes, and generic so I can add other functionality later if needed without having to rename the class (Ex, Extended, Custom, etc).

Of course, if the control does something specialized that is unlikely to be wanted in other cases when using that control, then I'll add a more descriptive suffix to the control name instead.

I also add the word at the end of the control name (TreeViewCustom instead of CustomTreeView) so it pops up in auto-complete when you try and use the standard control.

Rachel
  • 23,979
  • 16
  • 91
  • 159
  • the drawback of this kind of naming is that it isn't descriptive or self-explanatory, for example, when you saw code using TreeViewEx in several times in the application, the reader has no immediate idea why it is used and how it is different from the normal tree view – Louis Rhys Nov 20 '12 at 14:42
  • @LouisRhys Yep, that's why I specified its only used for generic extensions of the class that you will probably want everywhere. For example, I have a `TabControlEx` that prevents each `TabItem` from getting unloaded when switching tabs, which is a functionality I always want when using a `TabControl`. As for a description of what's changed in the extended class, I add a summary of that to the top of the class file in the `///` comment block describing the class. – Rachel Nov 20 '12 at 14:53
  • +1: The overly specific names will break as soon as someone else changes the behaviour or adds more. I've also seen the suffix _Decorator_ used (cause, really, that's what the OP is describing). – Steven Evers Nov 20 '12 at 17:06
  • another thing, is that there is already a class ExtendedTreeView, and when I checked it has some behaviours that I don't want to use. If I add another similarly named class it will just confuse people. – Louis Rhys Nov 21 '12 at 02:01
  • @LouisRhys Understandable in that case. Typically if I add anything to my generic class that I may not want in every case, I add a property to allow me to enable/disable it. – Rachel Nov 21 '12 at 03:13