Reorder arguments in decorator methods

I have a few decorator methods that have various behaviours including rate limiting, timing, and of course, circuit breaking! I apply these in a chain, as per the decorator pattern.

CircuitBreaker.decorateSupplier has a type signature Supplier<T> decorateSupplier(Supplier<T> supplier, CircuitBreaker circuitBreaker), so chaining multiple decorator methods looks like:

RateLimiter.decorateSupplier(rateLimitConfig,
    CircuitBreaker.decorateSupplier(
        Stopwatch.decorateSupplier(stopwatchConfig,
            mySupplier()), circuitBreaker));

Notice that the CircuitBreaker instance is far from where it is applied in the chain, and looks out of place.

If CircuitBreaker.decorateSupplier had a type signature of Supplier<T> decorateSupplier(CircuitBreaker circuitBreaker, Supplier<T> supplier), then the same code would look like:

RateLimiter.decorateSupplier(rateLimitConfig,
    CircuitBreaker.decorateSupplier(circuitBreaker
        Stopwatch.decorateSupplier(stopwatchConfig,
            mySupplier()));

Now it’s easier to associate the CircuitBreaker instance with the call to CircuitBreaker.decorateSupplier

[RobWin]

Hi, indeed. Looks much better that way.

If you use the library, I would love to get your GitHub Star.

[RobWin]

Let’s move the discussion to #12. Could you copy your comment into this issue? Besides that, @tomfitzhenry is not the maintainer, but it’s me 😃

If a RateLimiter implementation is lightweight in the sense that we don’t need any other 3rd party libraries, we can add it to javaslang-circuitbreaker. A RateLimiter is also some sort of CircuitBreaker. A RateLimiter can forbid further calls, if a rate limit has exceeded.

The retry functionality is also not 100% related to CircuitBreakers.