http://www.carlopescio.com/2011/04/your-coding-conventions-are-hurting-you.html

Alan is very explicit about the idea of methods as goals, something you want to happen, unconcerned about how it is going to happen.

The fundamental reason behind TDD.

If we can’t find a good name, we obviously don’t know enough about either the problem domain or the solution domain.

I would suggest that you focus on class/interface names first. If you can’t find a proper name for the class, try naming functions. Look at those functions. What is keeping them together? You can apply them to… that’s the class name :-).

When Peter wrote that (1993), the idea of an Helper class was mostly unheard of. But as more people got into the OOP bandwagon, they started creating larger and larger, uncohesive classes. The proper OO thing to do, of course, is to find the right cooperating, cohesive concepts. The lazy, fake OO thing to do is to take a bunch of methods, move them outside the overblown class X, and group them in XHelper. While doing so, you often have to weaken encapsulation in some way, because XHelper needs a privileged access to X. Ouch.

Wow, I’ve never paid attention to that since helper class is so much “needed” for every project. Lol

Handler, again, is an obvious resurrection of procedural thinking. What is an handler if not a damn procedure? Why do something need to be “handled” in the first place? Oh, I know, you’re thinking of events, but even in that case, EventTarget, or even plain Target, is a much better abstraction than EventHandler.

Again, eye opening!

Still, at some point people thought it was fine to look at an interface (or at a class), see if there was some kind of “main method” or “main responsibility” (which is kinda obvious if you only have one) and name the class after that. Which is a very simple way to avoid thinking, but it’s hardly a good idea. It’s like calling a nail “Hammerable”, because you known, that’s what you do with a nail, you hammer it. It encourages procedural thinking, and leads to ineffective abstractions.

Unusual perhaps, but that’s because of the common drift toward the mechanics of things and away from concepts (because the mechanics are usually much easier to get for techies).

Sort of calling a concept IDollar instead of Currency.

A List is an IEnumerable (what??) A List is a Sequence (well, all right!)