Jimbo vs. The Tooltip
| Here Are Your Choices! | ||
|
|
|
Perhaps you already have a strong preference just from looking at them; that's fine. Instead of debating and declaring one a winner, lets examine how I arrived at my own decision, when I was recently faced with this question.
Nested classes + intellisense
= easier for developers
I was considering refactoring to the nested class scenario. I've grown somewhat fond of nested classes for their ability to group things together and for the way intellisense can provide targeted hints with its dropdown suggestions. Instead of trying to hunt down a TastyAppleStrategy or UnripenedAppleStrategy and wonder what else may exist, you can just type "Apple." and see all available choices. without ever hitting comments or navigating code. Its all right there for the developer stuck trying use my convoluted code. O 'course, get too nested and you've just got a rats nest.
It doesn't matter how brilliant or easy my code is, because my target audience (another developer) didn't write the code himself. And your code, regardless its nature, is always regarded as unintelligible goobledygook by other developers. As a general rule, being forced to understand it has pissed them off as well. They want to deal as little as possible with your code, so they can go back to writing their own. Everyone understands their own code, they've spend their whole life writing their own code; it makes sense. Even if you disagree on the merits of nested classes, let's assume for what follows next that they are roughly of equal merit. The main usage point was this function:

But what really happened with nested classes was less friendly tooltips:

Oh jeez, my meticulously constructed fantasy world crumbles around me. What if I abandon the refactor and stick with a flattened structure:

A flattened structure yields the most helpful tooltips. Since invoking DoSomething is the main use-case for developers-who-aren't-Me, I chose the one that's better documented by the IDE.
So, that's how I arrived at my choice. Seriously: The tooltip. Not like I planned out success criteria and did a focus group. More like 90% into the change to my obviously brilliant nested classes I noticed the tooltip, went "Aw Fuck!" and reverted the changes. The tooltip rules all!
There are a few points I'm attempting to make. One is to consider your target audience: other developers. Lazy, couldn't be bothered, highly overworked, incompetent, brilliant, will not read any specs, enjoy puzzling things out, developers. Naming and structuring your code is the biggest documentation you are likely to perform in any given project and there's a lot of potential things to guide your decision.
Much is written elsewhere involving the pursuit of technical excellence. Ways to code that in and of themselves that are beautiful monstrosities with no regard to the environment they inhabit. The best solutions integrate with the ecosystem of developer tools. "The Best Way To Code" stopped being an isolated academic question sometime around when our variables got colour-coded. The right(est) answer depends on your coding environment, Visual Studio version, your team-members, their prior experience and skill levels, what code-generators you're using -- you gotta consider it all. Which is ultimately impossible. If you want definite answers, go believe in creationism.
You could do worse than consider tooltips in your next design. And when Visual Studio changes their tool-tips next version, you betcha: Its time to refactor that code. The Game just changed and everything I said is antiquated.