I like the Ruby on Rails "RESTful routes" convention: each controller represents a resource (a noun), and there are 7 conventional actions:
Note that resources don't have to map directly to models/database tables - for e.g. password reset, you may "create" a password_reset resource to request a new password, and "update" it to set the new password, even though behind the scenes, it only modifies your user model.
Why do you need to extend this class? And why do you need to name your own method the same as showDialog
?
In reality your method does something entirely different than what showDialog
does. A better name for your method would be showDialogAtLocationAndReturnSelectedFile
as your method does more or less these things. Naming it showDialog
will only confuse your code users.
Also, without knowing anything else, I'd say you're trying to shove too much in a single method. How do you react on a cancel press? How about an error? Do you return null? If so, you're forcing the user of the code to check the return value yet again. This has the potential of being just another "Leaky Abstraction", and Java APIs already have enough of these.
An important part of API design is making sure that the name of a function/class/method matches what it really does. And that is why in JFileChooser
the method's name is showDialog
. It just shows the dialog. It doesn't open the file for reading, it doesn't perform a check whether the filename is valid, and honestly, why would it? The user of the code just asked the class to show the dialog.
The creator of Ruby calls this the 'Principle of Least Surprise'*, and while I don't really know Ruby, this is a great line to learn from. Your code should be in the service of its user, and a part of this service is embedding the contract of the method/class in its name.
You might think you're not designing an API, but I doubt you work alone: there's probably someone else in the team, and they will appreciate this. Also, I heartily recommend this lecture on API Design: How To Design A Good API and Why it Matters. It was presented to Googlers by a Java designer, so it kinda matters.
Maybe this is more than you asked for, but I feel you seem to be somewhat missing the point of naming methods.
UPDATE: * I seem to be mistaken, the creator of Ruby has actually stated that he designed Ruby with the "Principle of Least Astonishment", not "Principle of Least Surprise". In any case, what I said still holds.
Best Answer
Is vs. Can
According to the Microsoft naming convention recommendations, both "Is" and "Can" are OK (and so is "Has") as a prefix for a Boolean.
In plain English, "Is" would be used to identify something about the type itself, not what it can do. For example,
IsFixed
,IsDerivedFrom
,IsNullable
can all be found in CLR types and methods. In all of these cases, "Is" is followed by an adjective.Meanwhile, "can" more clearly indicates a capability, e.g.
CanEdit
,CanRead
,CanSeek
. In each of these cases, can is followed by a verb.Since "Support" is a verb, I think in your case
CanSupportContentType
is better.Shorter alternative
On the other hand, the conventions say the prefix is optional. What's more, it's kind of cheesy to include the argument type in the method name, since a developer can see the type of the argument in intellisense. So you could just name your method
Supports
and define it like this:...which is shorter and still clearly communicates the purpose. You'd call it like this:
Or as a compromise maybe this is best: