A pattern of names you'll see in objecty code:
I consider it a smell, but I'm not sure if I'm justified. It's redundancy, to be sure... but is it the bad kind? What are your alternatives?
Looks to me as if the root cause of the odour here is not so much redundancy (that's merely the symptom) as sloppily chosen abstractions. How about this style:
This is not a CodeSmell
. It does not imply anything about the quality of the abstractions or structure of the code; it only reflects the arbitrary nature of available words in the vocabulary of the domain. For example, Pilot.controlAirplane()
seems like a perfectly reasonable class/method name combination. But what if English didn't have the word 'pilot', or the programmer just didn't have that word in his/her vocabulary? Then the obvious choice would be AirplaneController.controlAirplane()
, which is exactly the same abstraction but would be a smell. Similarly, saying that General.command()
is fine but Commander.command()
smells doesn't make sense. Reorganizing the code to avoid these obvious and clear choices of class/method name would be inappropriate. This even applies to the page title itself. The word "Verber" here is used to refer to something that more commonly called an "agent". Is there a problem with AgentNounDotVerb constructions?
It could even be argued that, rather than being redundant, VerberDotVerb
actually increases consistency and strengthens the relationship between class and method. After all, if you want to find the the parsing code in a program, you would look for a class named Parser
, and not for Expression
. (In fact, I think Expression.parse()
smells: expressions don't parse things.) For classes that only have one significant method, this pattern makes a lot of sense.
is a little ugly, especially when every class you have follows the pattern. But it doesn't signify anything fundamentally wrong that needs fixing.
constructs appear in my code when a class has one public method that does all of the real work. In that case, it makes sense to name the class Verber and the method Verb. Though I make the class name more specific when it's feasible, such as XmlParser?
.parse() -- JaredLevy
If a class has only one public method, it should just be a function.
(...) is better than
Are you objecting to Fooer.foo() or fooer.foo()? A member function foo() of a class Fooer is probably not usually the best thing but I may choose to use: Baz fooer; fooer.foo(). I would use this if fooer is passed in as a parameter to a function that only cares that fooer has a method foo. -- AndrewQueisser
More to the class one than the instance one. Though, I can't say I wouldn't sniff around if the instance one had the VerberDotVerb pattern. Why not use its class's noun name?
It may say more about your choice of implementations than anything else. In C++, you would normally use operator (), such that
If the former smells, but the latter doesn't, this suggests to me that the VerberDotVerb
pattern is a language smell, rather than a code smell.
See also : VerbSubject
, Execution in the Kingdom of Nouns http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html