3 ms·
"start breaking up functionality that logically belongs together and can't be reused in other contexts" I know you said you're in the C++ world, so I don't thi
by virmundi 13y ago
"start breaking up functionality that logically belongs together and can't be reused in other contexts"
I know you said you're in the C++ world, so I don't think what I'm doing fits yours, but I've responded to the same behavior in the Java world in a way that tends to confuse and mystify my co-workers. In Java I've started to declare classes within methods. These classes can compute complex processes, but are nicely tucked away in the only logical place they make sense, that method.
My reason for this is that the method really belongs to the containing class. I can't break it down or abstract it out. I could use composition, but the new method-class isn't usable by anything else. The sub steps in the method aren't usable by any other method within the housing class. I could put them there, but they would just muddy the outer class. So now the code looks something like this.
public class Outer {
void doSomethingComplex(final params) {
class ComplexThing {
private void step1() {...}
private void step2() {...}
public void goToTown() {...}
}
new ComplexThing().goToTown();
}
}
ComplexThing gets access to the outer params. This cuts down on constructor complexity and cements the intricate bond between the two entities, method and inner class. The logic is broken down nicely. Finally, nothing is needlessly shared.
This might make the outer class a bit larger, but I find this structure pleasant.
It's also a useful pattern for writing tests. Each test method gets a class (could have inheritance) that has a setup, test, tear down. All of that is encapsulated in one place.