What if there is no module on the module path that provides a suitable implementation of Matcher? What if there is no implementation of that interface at all? In this case, it is possible to provide a default implementation alongside the public API. The benefit is, that once the API module is distributed, it can definitely be put to use, even if the default implementation does not exhibit the quality aspects that we aimed for. Providing a default implementation is quite simple.

One of the shortcomings of the previous solution is that we are yet unable to select a provided service based on non-functional characteristics. As a user, I do not care if the chosen string matcher follows the design of the Knuth-Morris-Pratt or the Boyer-Moore algorithm. Instead, I want it to be stable and fast. If there is a new, but yet not thoroughly tested matcher available, I may want to use that for an experimental client. When we think in terms of suitable implementations for the problem we try to solve, we do not think about implementation internals at first, but rather about the non-functional requirements that govern the process of finding a suitable solution.

Although we progressed through to a working, modularized solution for our string matchers during the last article, we still have an unwanted dependency that goes directly from module matchers.cli to matchers.impl. This prohibits us from using a clean and extensible way of injecting implementations of the Matcher interface. Working through this article, our goal is to end up with a very loose coupling between our Java modules by implementing a mechanism for that kind of dependency injection.