4 ms·
Interesting. But it looks like it is solving a problem with another problem. The receiving class would then look like this: public void doSomething(Name na
by columbo 14y ago
Interesting. But it looks like it is solving a problem with another problem. The receiving class would then look like this:
public void doSomething(Name name, Link link, UltimateAnswer ultimateAnswer, TempFile tempFile, Zip zip) {
String name = name.name;
String link = link.link;
int ultimateAnswer = ultimateAnswer.ultimateAnswer;
String tempFile = tempFile.tempFile;
int zip = zip.zip;
}
If the problem is "I don't like these SAME values being used all over the place" then use DEFAULTS.
o.doSomething1(); //defaults to "Alfred","c:\\temp",42,"shadurhaft.de",23
That or pass in an object.
o.doSomething1(mySomethingObject);
If the values are genuinely different then the only way to solve this problem is to validate the options (paths should be a valid file location and not a website, websites should be a valid website etc) and then (possibly) pass in an object instead of primitives.
I don't see encapsulation doing anything really, aside from increasing the number of "junk" classed by about a hundred fold.
Why throw standard convention out the window?
- peeters 14y agoI'm not sure I see the "another problem" you're referring to. Can you describe the problem with the new implementation of doSomething()? Also, I don't think the original problem was the same values being used all over the place. The problem is how to be clear about which parameters you're providing, and accepting static types and giving the type a simple way of constructing it solves that.
- jlgreco 14y agoThe other problem is that int zip = zip.zip; is just silly, even by Java's standards.