Thread by @GeePawHill

Killing time while I wait for my birthday drink(s). I am prowling around a large java code base, looking at code I regard as "good", and partly picking nits and partly re-envisioning it in Kotlin idiom.

It is fun, sometimes, to look at bad code from lousy designers. But I am enjoying looking at reasonably good code from a designer I have a lot of respect for. Feels like it's even more fun.

A f'rinstance nit: don't use inline if's to handle pre-configured optional steps in an algorithm. Use a Strategy constructed at configure-time.

Example: some matchers for incoming request paths want to strip trailing slashes from the path before attempting the match. This is either configured at constructor time, or shortly thereafter, and is a fire-and-forget configuation choice.

So in your code to do this, you write:

function match(input) {
if(strippingTrailingSlashes) {
input = // .. whatever that takes.
}
// ... test for a match
}

A better choice? Define a strategies for stripping or not stripping slashes. When the value is configured, instantiate one of those strategies. Now, when you call match, *always* let the strategy pre-cook your input.

function match(input) {
input = slashHander.handle( input )
// ... test for a match
}

Somewhat weak names, but it's the concept that's important here. What are you getting?

1) Your code for match is now non-branching.
2) Your tests for the strategies don't have to call whoever's doing the matching.
3) In some cases, you'll actually get a performance boost.

In some real-world cases, there are a half-dozen or more of these optional "pre-cook" or "post-cook" options. In that case, consider making the Strategy's be decorators, so you can chain them.

A serious case? The splitpane in JavaFx. It has an Orientation field, which defines whether we're positioning its children horizontally or vertically. The algorithm, which stretches across several methods, tests that Orientation value over and over again, a dozen times.

The thing is? That Orientation *never* changes during a run of the algorithm. (It can change during the lifetime of the object, but not during a run of the layout.)

But there are dozens ternary operators all through the code, effectively if's, that are saying orientation==Vertical?y:x. It makes the code incredibly noisy and hard to understand.

A strategy would make the code far easier to grasp and change. There are two strategies, one for VERTICAL, one for HORIZONTAL. They could simply *always* be called, and will always do the right thing.

(There's an even better answer, btw, having almost nothing to do with this topic. Have a Stategy that does/doesn't swap x and y on the way in and the way out. Now you only call that Strategy at the beginning and the ending of layout.)