anchor.diff:  == Google Guice
   Dependency Injection as a concept is not difficult to grasp. However, complex projects need to inject multitudes of configurations in multiple different places, and so DI easily becomes a burden.
   
  -Google Guice to the rescue! Guice is a DI framework oriented to simplicity and in-code configuration through the power of decorators. First, we need to add the dependency to the project `pom.xml`:
  +Google Guice to the rescue! Guice is a DI framework oriented to simplicity and in-code configuration _through the power of decorators_. First, we need to add the dependency to the project `pom.xml`:
   ```
       <dependency>
           <groupId>com.google.inject</groupId>
  
positive.code:     }
  }
  ```
  If all it was like this, it would not be such a pain after all. However, things get complicated when it is not the frontend `App` class that uses the DataSource object, but some internal class. For example, a common pattern in enterprise Java is to have a Repository class that abstracts data manipulation for the frontend `App` class -- there are several reasons why this makes sense, like for example the mantainability according to SOLID design.
  So let's assume instead that `App` has a reference to `Repository` and that it is `Repository` that needs a `DataSource` instance. Something like:
  ```
  public class App {
  
negative.code: 
  More precisely, you have to master few different variants: if you get the implementation from a factory (like in our example), you have to use the `.toInstance()` DSL, but if you get the implementation from a written class, the correct syntax is `.to()`.
  
  There is a little other step to do in the actual `App` class code, and is to retrieve the configured implementation in `AppConfig` within the `App` class itself, using the `Guice::createInjector` function:
  ```
  public class App {
      public static void main(String... args) {
  