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.
These functions both have to do with collisions, but what they do is very different, so giving them names that more clearly describe what they actually do will make it easier for future developers to understand the difference without having to look at the logic inside.
The method that checks if the object is colliding with another object could be called checkForCollision
.
The method that resolves collisions of the object with other objects could be called resolveCollisions
or handleCollisions
.
When two functions do almost the same thing is often the best time to give them more specific names to make their difference clear.
Best Answer
I vote for "Giving the methods different names" option especially if performance matters.
Don't use
andmethod1(int[][])
.method2(int[][])
Use
method(int[][])
andmethod_transposed(int[][])
for example.Method name should always help the reader to understand what it does.