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).
You call a constructor when you want to create a new object instance. For example if you have a class Button
, then you call the constructor if you want to create a new Button
instance.
If you don't need a new object, then don't use a constructor. In your example you just use the constructor as a convoluted way of calling a method, but you don't actually use the created object (the result of the new
-expression) for anything. This is a clear hint that you don't need to call a constructor. If you made saySomething
static you would not need to call any constructors.
The reason for your confusion is probably that the HelloWorldConstructor
class does not really have any purpose beyond writing output. Therefore it is not obvious whether you should have one or two instances of it. In reality you don't need any instance at all.
Best Answer
Hell, no! It's horrible.
Create a class which has those things as fields and return an instance of that class. Furthermore, that class can have methods which use the data to do useful things. That's what OOP means: put the logic where the data is instead of ferrying around the data between procedures.