The problem here is the signature of setLocation
. It's stringly typed.
To elaborate: Why would it expect String
? A String
represents any kind of textual data. It can potentially be anything but a valid location.
In fact, this poses a question: what is a location? How do I know without looking into your code? If it were a URL
than I would know a lot more about what this method expects.
Maybe it would make more sense for it to be a custom class Location
. Ok, I wouldn't know at first, what that is, but at some point (probably before writing this.configuration.getLocation()
I would take a minute to figure out what it is this method returns).
Granted, in both cases I need to look some place else to understand, what is expected. However in the latter case, if I understand, what a Location
is, I can use your API, in the former case, if I understand, what a String
is (which can be expected), I still don't know what your API expects.
In the unlikely scenario, that a location is any kind of textual data I would reinterpret this to any kind of data, that has a textual representation. Given the fact, that Object
has a toString
method, you could go with that, although this demands quite a leap of faith from the clients of your code.
Also you should consider, that this is Java you're talking about, which has very few features by design. That's what's forcing you to actually call the toString
at the end.
If you take C# for example, which is also statically typed, then you would actually be able to omit that call by defining behavior for an implicit cast.
In dynamically typed languages, such as Objective-C, you don't really need the conversion either, because as long as the value behaves like a string, everybody is happy.
One could argue, that the last call to toString
is less a call, than actually just noise generated by Java's demand for explicitness. You're calling a method, that any Java object has, therefore you do not actually encode any knowledge about a "distant unit" and thereby don't violate the Principle of Least Knowledge. There is no way, no matter what getLocation
returns, that it doesn't have a toString
method.
But please, do not use strings, unless they are really the most natural choice (or unless you're using a language, that doesn't even have enums ... been there).
The practices of adding meaningful prefixes to symbols, such as the well-publicized Hungarian Notation, date back to the times when IDEs did not exist or were too primitive. Today, when finding a point of declaration is a mouse click away, there is no point in spoiling the most precious part of the name, its first few letters, by assigning a common prefix.
Best Answer
Identifiers should not repeat information that is already indicated by the types. So
findAppleByString()
andfindAppleByInteger()
would be redundant. But in your case the function names add the information that the integer represents an ID and the string represents a cultivar name, which is not indicated by the type system.You could also have multiple search methods using the same parameter type, e.g find by ID and find by weight, where the parameter in both cases was an integer. So you would need to distinguish the name.
So the first example seems to be more informative and more flexible, and therefore the better choice.