I, on the other hand, don't, and I'm suprised to hear that you do
(unless you mean that comment in a somewhat sarcastic way).
Yes, it's that the variable is used to convey one type to the compiler and
a different type to the reader, all the while hiding that this reviled
feature is used.
Interestingly, if the SomeClass.someStaticMethod() syntax was not allowed,
this technique could be used to fake it.
In fact,
this seems like so obviously a very bad idea that I would seriously
question the wisdom of leaving someone employed after they pull a stunt
like this. If a couple people have been allowed to do things like this
over an extended period of time, it may well be time to scrap the
project and rewrite from scratch.
Of course you don't do such a change willy-nilly, but if you have a size
constraint and you can't cut functionality, I don't see much choice other
than getting rid of everything that isn't needed, including cutting classes
that do nothing more than group together related methods.
Competent software people do sustainable work. That's the bottom line.
But that's the point, to sustain the conseptual divide between Util1.foo(),
Util2.bar() and Util3.baz() in the face of them moving to a single class.
You could rename them to util1_foo(), util2_bar() and util3_baz() and
retain most of the original design, but this way you don't have to change
every call-site and you don't (necessarily) need ugly prefixes, even though
they are a good idea.
Perhaps an extended example makes the advantage clearer. Util1, 2 and 3 as
before. Starting point:
class Main { main() { Util1.foo(); Util2.bar(); }}
class Other { other() { Util2.bar(); Util3.baz(); }}
Option 1: Move utility methods to Main using prefixes:
class Main {
// prefixed foo(), bar(), baz()
main() {
util1_foo();
util2_bar();
}
}
class Other {
other() {
Main.util2_bar();
Main.util3_baz();
}
}
Option 2: Move methods and introduce variables for them to be used thru:
class Main {
// normal foo(), bar(), baz()
// variables for Util1, Util2, Util3
main() {
Util1.foo();
Util2.bar();
}
}
class Other {
// variables for Util1, Util2, Util3
other() {
Util2.bar();
Util3.baz();
}
}
In option 1, the main() method stayed relatively stable, but the other()
method was altered greatly. In option 2, both main() and other() remained
as they were. Any meaning that the Util1 class name conveyed before is
still conveyed in full.
