anchor.diff:      }
   }
   ```
  -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.
  +In this case switching from a DataSource implementation to the other 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 {
  
positive.code:     @Test
      public void test1() {
          repo = new Repository(ds);
          .... test ...
      }
      
      ... other tests...
  }
  ```
  Of course it could be the case to totally create a database mock (e.g. using Mockito) instead of relying on H2 for testing. It does not matter though, because in the `@Before` function we would just write `ds = mock(DataSource.class)` instead of taking an implementation from `Factory`, but the injection of `ds` into `Repository` would still be done in the same way (the tests would not change... nice!).
  
negative.code:     private DataSource ds;
  	public Repository() {
          ds = Factory.getH2DataSource();
          ...constructor...    
      }
  }
  ```
  What happened now, is that the `DataSource` is not manageable anymore from the frontend. Granted, if we want to change the `DataSource` impl to be the `Factory::getPostgresDataSource` instead of the original, we can go to the `Repository` class and tweak the `ds = ...` line. The problem is that if there are more other "middlemen" in the app structure other than `Repository`, that need to use a `DataSource` instance, things will go awry pretty soon: if by mistake we are using, say,  `DataSourceImpl1` in one part of the code and `DataSourceImpl2` in another part of the code, what is going to happen?
  
  So the only solution is to centralize somewhere the "configuration" of what `DataSource` implementation we want to use, say, in in the `App` class itself like we were doing originally, and to *inject* the chosen `DataSource` implementation from there into `Repository`. In other words: we have to change the `Repository` code so that the `DataSource` *dependency* is *injected* in the constructor by the caller, instead of being created over there: 
  ```
  public class App {
      public static void main(String... args) {
  