title: Extending a generic class and implementing its interface for the second time
body: <p>I would like to present a scenario where it would be nice to:</p>
  
  <ul>
  <li>have a generic interface,</li>
  <li>have various generic base classes implement it,</li>
  <li>provide subclasses for the generic base classes,</li>
  <li>somehow get a non-generic interface to the subclasses.</li>
  </ul>
  
  <p>Confused? Read on and tell me what you think about the solution.</p>
  
  <p>Let's say I want a service to provide any kind of object based on any kind of key
  and from anywhere (DB, file etc).</p>
  
  <p>For a good start let's create a proper interface:</p>
  
  <pre><code>public interface ObjectProvider&lt;K, V&gt; {
  
      V provide(K key);
  }
  </code></pre>
  
  <p>In this way I will be able to provide any kind of implementation.
  I want to provide objects from a database and a file.</p>
  
  <p>Let's assume that providing V based on K can be done with the same
  DB logic regardless of object types. So I can write a generic base class
  for DB access:</p>
  
  <pre><code>public class DBObjectProvider&lt;K, V&gt; implements ObjectProvider&lt;K, V&gt; {
  
      public V provide(K key) {
          V v = null;
          //some common DB logic to get V based on K
          return v;
      }
  }
  </code></pre>
  
  <p>Actually, getting objects from a file is also object type independent:</p>
  
  <pre><code>public class FileObjectProvider&lt;K, V&gt; implements ObjectProvider&lt;K, V&gt; {
  
      public V provide(K key) {
          V v = null;
          //some common file reading logic to get V based on K
          return v;
      }
  }
  </code></pre>
  
  <p>Ok, by now I have two generic classes that I may use to get anything I want.</p>
  
  <p>Now, I want to use one of those generic implemenentations to get a String object based on a String key from a database. Additionally, I want to it defined as a bean using Spring XML.
  I guess there is no way to define a generic bean in Spring XML (am I right?) so I
  will create a proper class instead. All I need to do is:</p>
  
  <pre><code>public class DBStringStringProvider extends DBObjectProvider&lt;String, String&gt;  {
  }
  </code></pre>
  
  <p>Right now I can inject this bean into any:</p>
  
  <pre><code>private ObjectProvider&lt;String, String&gt; objectProvider;
  </code></pre>
  
  <p>All is fine, now the key part.
  I could make use of my useful DB String-String provider in a lot of ways (hhmmm... ok not really). Let's say I want to make a web service out of it.
  Suppose I want to expose DBStringStringProvider as a CXF web service and test it.
  The problem is that the client code for such a web service looks like this:</p>
  
  <pre><code>JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
  factory.setServiceClass(&lt;INTERFACE&gt;.class);
  &lt;INTERFACE&gt; client = (&lt;INTERFACE&gt;) factory.create();
  </code></pre>
  
  <p>so I need a non-generic interface for DBStringStringProvider which I don't have because it extends its generic base class.</p>
  
  <p>I can do the following:</p>
  
  <p>Extend the ObjectProvider&lt;String, String&gt; interface with another one:</p>
  
  <pre><code>@WebService
  public interface StringStringProvider extends ObjectProvider&lt;String, String&gt; {
  
      @WebMethod
      String provide(String key);
  }
  </code></pre>
  
  <p>Additionally implement it where it is sort of already implemented by the generic base class:</p>
  
  <pre><code>public class DBStringStringProvider extends DBObjectProvider&lt;String, String&gt;
  implements StringStringProvider {
  }
  </code></pre>
  
  <p>I'm feeling a little bit uncomforable about implementing the same interface where it is already introduced by the base class.
  But in this way I'm able to make use of the WS client:</p>
  
  <pre><code>factory.setServiceClass(StringStringProvider.class);
  StringStringProvider client = (StringStringProvider) factory.create();
  </code></pre>
  
  <p>My question is: Is it a good practice to do what I just did? If not, is there any other way?</p>
  
  <p>This is just one scenario where it would be great to have a non-generic interface for something
  that has been defined generic.</p>