Re: refactoring problem
Arved Sandstrom wrote:
Roedy Green wrote:
Consider the following refactoring problem.
There is a hunk of almost identical code that appears multiple times.
It sets up 6 local variables.
I would like to encapsulate it.
The obvious way to handle it is to make all the variables instance.
But they are ARE local. (I might be using threads)
Further their declarations would be scattered to the winds.
I could create a separate class just to hold the values. This is
tedious, but it may be the only way.
It might be tedious, but programming is a cost-benefit exercise.
If you have six variables that are so tightly bound semantically that
you consistently want to treat them as a unit, then you have a type.
The right thing to do with a type in your programming model is to
implement it as a type.
I think that's a decent way of handling this problem in Java.
Or any OO-ish language.
I think, why can methods have multiple inputs, but only one output? I
have been thinking that for about 50 years, and it ,seems unlikely to
change soon.
How exactly would you expect multiple outputs to work? If you've been
thinking about this for about 50 years, then we're talking pretty much
any programming language out there. Apart from the technique of defining
And a classic inquiry.
a single object or struct to hold multiple return values, you have other
languages that support returning lists or tuples. You do have languages
A tuple is roughly equivalent to a struct or class with the same number
of elements.
If tuples or types do not require explicit declaration, then we have
something like dynamic types.
If we had a strongly-typed tuple language that was as rigid about
declaration of tuples as Java is about types, we'd have comparable
tedium.
(Scheme, for example) that return "true" multiple values from
procedures, I don't see that their techniques have large advantages over
tuples myself.
And then of course there are things like generators, or for example,
lazy evaluation of a map function over a list.
Maps are like the poor-man's dynamic type. They're lovely little data
structures.
What else would you have in mind?
Here's the thing. No language has it all, otherwise there'd be no programs
left to write.
So somewhere between that _reductio ad absurdum_ and the abacus each
programming language has to choose a subset of tools, an axiomatic set
if you will, that becomes core to the language. The rest you write yourself.
You can do what you want in this case, and in this case it will be better
program design anyway, by writing a type to express the relationship among
those six things you represent as variables.
Too bad for you that you find it tedious.
Sometimes a great chef has to chop onions, though it make them cry.
--
Lew