DokChess invites developers to experiment and to extend the engine (→ 1.1 Requirements Overview). In order to do so, the modules are loosely coupled. DokChess modules are implementations of Java interfaces. Java classes that require parts signal this with appropriate methods set«Module»(«Interface» …). They don’t take care of resolving a dependency, for instance, by using a factory. Instead, the client resolves the dependencies by creating suitable implementations with new and putting them together with setter methods (also known as Dependency Injection, short DI).
Interfaces and DI enable alternative implementations within DokChess. Adding functionality with the help of the decorator pattern (Gamma+94) is possible as well. Furthermore, aspect-oriented programming (AOP) solutions, which rely on Java dynamic proxies, are applicable interfaces. Plus, this handling of dependencies positively affects testability (→ 8.7 Testability).
DokChess abstains from the use of a concrete DI framework. The modules are hard-wired in the code, however only in unit tests and glue code (for example, the main class). No annotation driven configuration is present in the code.
This gives adventurous developers free choice regarding a specific DI implementation. Since the Java modules are pure POJOs (Plain Old Java objects), nothing prevents configuration with the Spring Framework for example or CDI (Contexts and Dependency Injection for the Java EE Platform).