I was inspired to ask this here based on this blog post. Do you always try to use nouns for class names?
Singluar nouns, yes. Verbs are for methods because they are performing an action.
Yes, unless it's an anonymous class.
If it's a class that only exists to perform some action then name it accordingly (ActionListener, for example).
Depends on whether the class represents a noun or not and whether you consider only the class itself or also its ancestor class(es).
For example, I did a game a while ago with an abstract "Order" class with concrete subclasses named "Move", "Attack", "Capture", etc. The abstract parent is a noun, but the concrete children are verbs. (Possibly relevant: This is in Perl so, by convention, the full name of the class is "Order::Move", etc., providing context which would otherwise require naming the subclass "MoveOrder" (a noun).)
This is a fairly typical pattern for me when dealing with a group of verbs, though - a noun-named parent class with verb-named children. I would expect that the same would apply for other parts of speech as well, although I can't really come up with a non-pathological case where creating separate Speed::Fast and Speed::Slow classes would be warranted.
Another yes. I can't say that I make a concerted effort to do so, but all of my classes end up being named after nouns because that makes sense. If it didn't make sense in some situation, I would not stick to it as a rule.
An implementation of the Command pattern would do well to have verb class names.
I could be wrong but I think that you've missed the point of the blog post. I think the author pretty well sums it up with:
"Object Oriented Programming puts the Nouns first and foremost. Why would you go to such lengths to put one part of speech on a pedestal? Why should one kind of concept take precedence over another? It's not as if OOP has suddenly made verbs less important in the way we actually think. It's a strangely skewed perspective. As my friend Jacob Gabrielson once put it, advocating Object-Oriented Programming is like advocating Pants-Oriented Clothing."
His point being that a proper language should provide facilities for both functional and object-oriented programming methodologies.
So a more appropriate question to ask based on the post is whether the author is correct in his declaration that OOP should not eclipse functional programming but that they should exist as equal entities and partners in development?
I myself have had this discussion numerous times and as a PHP developer I frequently take advantage of its dynamic typing as well as its functional and object-oriented capabilities. I tend to lean toward object-oriented solutions but there are times when you need a simple stand-alone function that doesn't fit nicely into a specific class.
yes - in english, nouns are for things, verbs are for actions/relationships
Exceptions:
- Command classes are normally verbs (Login, Logout, Create, etc..)
- State classes are normally adjectives (Closed, Open, Locked, Unlocked, etc..)
- Utility classes are normally plural nouns (Collections, Beans, Math, etc...)
EDIT:
@Thomas Owens makes a good point that commands can be suffixed with Command to become LoginCommand. Similarly states can be suffixed with State to become ClosedState.
I name my objects after PROnouns. They're usually short and easy to type. And whose going to forget "it"? Of course, I tend to run out of them quickly, so when that happens I tack on an adverb.
MeQuickly reactorCore = new MeQuickly();
reactorCore.Temperature = ThemGently.GetTemperature();
I think Yes. The only time I doubt myself is when there is a temptation to create a class that provides a certain service and sounds like a noun - for example FileParser or SpellChecker. Can't I just have a simple object (take SpellChecker as the example) and send it words to check? It can take in an object (a word) and spit out another (a boolean for whether or not the word is correctly spelled).
But the correct approach would be to have checkSpelling, the verb, as a method of whatever the word is typed as (likely String).