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).
To elaborate DeadMG's answer, it sounds like they mean:
Static array: an array whose size is known, and whose storage is allocated, at compile time. In C, you might write at global (file) scope:
int static_array[7];
Fixed stack-dynamic array: you know the size of your array at compile time, but allow it to be allocated automatically on the stack (the size is fixed at compile time but the storage is allocated when you enter its scope, and released when you leave it)
void foo()
{
int fixed_stack_dynamic_array[7];
/* ... */
}
Stack dynamic array: you don't know the size until runtime, eg. C99 allows this:
void foo(int n)
{
int stack_dynamic_array[n];
/* ... */
}
Fixed heap dynamic array: same as the 2 except using explicit heap allocation
int * fixed_heap_dynamic_array = malloc(7 * sizeof(int));
Heap dynamic array: you can probably guess this:
void foo(int n)
{
int * heap_dynamic_array = malloc(n * sizeof(int));
}
Is this the same book as Concepts of Programming Languages? Because again, these aren't a useful classification of types, they only address the allocation mechanism. Once you pass any of these "different" things into a function, their classification under this scheme is irrelevant.
Best Answer
From Robert Sebesta's Concepts of Programming Languages 9th edition:
Okay, what does that mean?
Stack Dynamic variables are allocated to the stack. Hardware in the case of native code. Software in the case of a a virtual machine. This means that they are pushed on to the stack when the code containing them is executed. Static variables on the other hand are bound and given values at load time when the program begins running.
How then is this useful? Well, functions generally get sent to the stack when they execute along with the passed parameters. In addition to being faster than the heap, this allows for recursive calls.
As a historical note, Elaboration as a term originated with Algol 68.